Microservices? Please Don't - <AUTHOR> https://dzone.com/articles/microservices-please-dont?oid=hn <comment><USER2> I'd like to hear some background from the author on his situation(s). Personally my current company is over 100,000 employees. We have a few 100 developers and many stacks, web apps, mobile apps etc. Our API is essential and is currently a giant monolith written by devs who no longer work here.

Splitting API code into repos based on endpoints allows us to have small easy chunks to deal with. It also allows us to drop those into containers and monitor and scale much easier. It also means instead of one API team, other devs can easily pickup a small code base and make changes for their stuff and, submit a PR for the API team. ]]

This article seems a bit elementary to have been voted up high on HN to be honest. It failed to acknowledge the true merits of doing microservices properly and the huge gains. Not all code bases are meant for microservices. However, huge monolith API's in general are a very good example where it's a perfect fit.

<comment><USER3> Why can't you split up your code into libraries? API doesn't have to mean "HTTP API", you're free to pick a different IPC layer.

<comment><USER4> I think the popular counterpoint has been - microservices _forces_ consideration of a good API because you are now on the network even if its just localhost.

<comment><USER5> I'd counter that they also force a lot of additional networked API boilerplate, and all new code is a potential source of bugs.

Perhaps it's better to break it into libraries with well defined APIs, and then break those libraries out into services when necessary. Jumping straight to the latter is going to create more room for problems than it solves.

<comment><USER2> Well we are rebuilding from scratch into micro services as we have the man power and money to do it. Why not just go with libraries? Here are the top five reasons off of the top my head.

The current monolith is requires vagrant and doesn't mimick production nearly as well as smaller containers.

This design will be easier to understand and with dev turnover that means bringing new devs up to speed faster. This is especially important when working with outside development firms which we do.

Deployments and scaling will be much faster. If one endpoint goes down it wont affect others. We are working to ensure one endpoint is not dependent on another.

When change is required in a certain part of the application, only the related service can be modified and redeployed.

No long-term commitment to a single technology stack

<comment><USER6> That sounds like most of the benefits you're describing simply due to redesigning the system with the benefit of experience and the much deeper knowledge about the problem which you learned building it the first time. Almost every point on your list could be restated in the opposite direction:

> The current monolith is requires vagrant and doesn't mimick production > nearly as well as smaller containers.

The decision to require use has nothing to do with microservice/monolith and you'd get the same consistency benefits if you deployed a large single application in a container as well, plus you'd have the added simplicity and debugging benefits from not needing to run additional applications for things like orchestration or service discovery.

> This design will be easier to understand and with dev turnover that means > bringing new devs up to speed faster. This is especially important when > working with outside development firms which we do.

Easier to understand is an aesthetic choice but it generally means things like a clean design, organization, good documentation, etc. which can be done in a monolith as well. Smaller services can encourage that but they don't necessarily – I've seen plenty of gnarly interdependencies and under- documented schemas – and they have a hard up-front cost that now all of your new developers will need to be able to start, reload, and debug many separate services and understand any interdependencies. If your culture and tooling can manage that well, it almost certainly could maintain a clean larger codebase following the same principles.

> Deployments and scaling will be much faster. If one endpoint goes down it > won't affect others. We are working to ensure one endpoint is not dependent > on another.

This is certainly the appeal but many places find that the scaling benefits are less than predicted because the business logic requires things which are harder than expected to separate or scale independently, and there's a cost to separation if that means that you're now forced to implement something like distributed transactions or locking on top of your own custom services.

Again, I think a team with the experience and support which can do this well in one model is also likely to have similar results with the other.

> When change is required in a certain part of the application, only the > related service can be modified and redeployed.

If you have a well-defined automated deployment process, this is a relatively minor benefit in either case. Assuming you weren't just running a single instance of the previous app, you need a way to handle things like blue-green deployment, managing schema updates, etc. no matter which design philosophy you pick.

> No long-term commitment to a single technology stack

This is one of the strongest arguments, but there is also a cost involved to having to learn and support multiple stacks. Again, I think that's more a function of culture and resources — I've seen places which were too conservative until they couldn't find developers at any price as well as places which had severe "Oooh, shiny" problems where every module was written in the latest thing the "lead" developer had seen that week.

Again, I'm not saying one approach is right or wrong but rather that it's too narrow a view to look at one practice in isolation. The microservice idea has been around for decades but it hasn't become universal because quality of implementation matters a lot and it's not optimal for all problems — I'm pretty sure the team at Oracle which built the deeply horrible business application I had to support about a decade ago used many of the same arguments to pitch the benefit of their enterprise Java web service architecture, which turned simple database queries into thousands of calls to services on a dozen servers. It's not that the concept was right or wrong but that it wasn't a silver bullet.

</comment></comment></comment></comment></comment></comment><comment><USER7> Here's an exchange between jedberg[1] and author Sean Kelly about a previous incarnation of this microservices article (September 14, 2016):

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

And in that same thread, in another response, SK writes:

 _> "I do wish I had titled it better, as most people have (rightfully) dinged me on this one ;)"_ \-- [https://news.ycombinator.com/item?id=12508941](https://news.ycombinator.com/item?id=12508941)

... and yet, here's another new article about microservices -- with another clickbait title. The subtitle then has the breathless, _" Continue reading to find out why."_

Serious non-snarky question to HN audience: do more than 50% really prefer this style of writing?

[1] I singled out jedberg's comment as significant because he discussed the costs and tradeoffs of microservices at 2 well-known companies (Reddit=no) (Netflix=yes). The interview transcript: [https://scaleyourcode.com/interviews/interview/11](https://scaleyourcode.com/interviews/interview/11)

<comment><USER8> No one cares if people prefer this writing, they only care if it's effective or not.

<comment><USER9> The accuracy of this statement is as depressing as it is apt.

</comment></comment></comment><comment><USER10> The author never discusses the most important pieces of microservices. The biggest one in my mind being organizational scalability. He talks about scalability from a performance viewpoint but not an org standpoint. Same with speed. Yes microservices add overhead and can be slower than a monolith, but they can give you autonomy and business speed. Business speed is so much more important than performance.

<comment><USER11> The author didn't discuss queues once. I work at a company that uses microservices and queues. Right now we use Rabbit, which is terrible for some reasons I won't get into, but the one good thing about it is that each message has to be acked. You take a message, you process it and then you make that you've processed it.

Things don't get lost. You can requeue messages that end up being dead- lettered due to bugs. You can scale the number of services that read from that queue. You can have services up independently if they just read and write from a system that says, "here's a chunk of data to process."

You can loose data with Rabbit, and if you're starting from the ground up you might want to look at something like Kafka instead. If you don't care about message loss and just need throughput (like if you're doing real time logs or sensor data), something like zeromq might be more appropriate.

The idea behind microservices is that you gain stability at the expense of some redundancy.

<comment> UK-AL We use queues + microservices. It's a good combo.

We also split the messages into different types, commands and events. A command is to perform a specific action and is normally aimed at a specific service. And event alerts any subscribed service that a action has happened.

So you send a CreateOrder command. After processing it would fire off a CreatedOrder event which any subscribed service could pick up(Such as a EmailService sending a confirm email). Allows you to create workflows, and monitoring systems quite easily.

I'm interested in your experience with RabbitMQ?

<comment><USER11> So you're using event sourcing then? We're doing the same thing using akka- persistence.

I'm not directly on the team that maintains our RMQ instances so I'm not the best to comment on it. Our dev-ops team have a complicated set of shovels and federation to deal with/minimize data loss, but I haven't had to delve into those scripts too much yet.

</comment></comment></comment></comment><comment><USER9> Hello all you nice folks on HN. Original author of the article here. A few things I'd like to add, since this is essentially what feedback I get every time this has made the rounds:

1\. I don't think microservices are bad, or that they don't work. Quite the contrary. My argument is simply that there is a lot of additional complexity in using this approach to your architecture, and to consider if you're able to handle that before diving in.

2\. This was adapted from a lightning talk I gave almost 2 years ago, and is almost by-design light on hard details or deep dives. It was meant to just introduce the problems by talking about fallacies (which many think are strawmen, but they're arguments that i've heard from people in my own discussions on the subject).

3\. Even if you disagree with my points, I appreciate folks taking the time to read and provide feedback.

Thanks!

<comment><USER12> I would like to respectfully disagree with you on most of your points (in the article).

1\. While network boundaries are not necessary, and in general add a little more overhead (and more boilerplate), it's a necessary evil. It helps you to think of each bit of software separately and in a way, helps you to find errors when they occur. I have worked with monolithic projects and while finding bugs is not hard, if it were a serverless micro-service, it'd be a lot easier.

3\. adding discipline as an abstract afterthought is a lot harder than just forcing discipline with micro-service projects.

4\. A not my problem approach might not be something to desire, but in my opinion, it helps in 2 major ways:

i) people are a lot more responsible for their code

ii) they don't make assumptions and take things for granted (a lot of error handling for example)

5\. Scaling micro-services (especially with AWS Lambda et al. is insanely easy and an afterthought). That is not the case for a monolith where you either have to keep worrying about scaling or re-write code.

I personally feel micro-services are the way to go. However, micro-services in general need a bit more guidance - best practices and so on and we have a lot more work to do before we get there.

</comment></comment><comment><USER13> Fallacy #4: Simple for Engineers "leads to 'not my problem' syndrome."

I've found the exact opposite happens with microservices. With well-defined interfaces and APIs, I know exactly where things are breaking and can pinpoint the service and code more quickly.

<comment><USER14> Right, but the problem is often pinpointed to someone else's team, and then you have to go communicate with them and convince them to make it a priority.

<comment><USER15> At my company this is the most crucial problem, people with different VP's priority than your VP's priority causes arguments that never end with anything being fixed. So you have to work around the problem which leads to hack upon hack.

<comment><USER16> At this scale though, you need service isolation just to operate with any efficacy. Think how much worse this case would be if those two rank and file developers under distant VP hierarchies were deploying the same codebase to the same production machines. Basically it would be impossible to ship without independent QA and Ops arms with heavy policy on what is required to deploy _anything_. Now you're moving at about 1% of the speed of a Facebook or Amazon.

</comment></comment></comment></comment><comment><USER17> I have this thing I say sometimes... "Which kneecap do you want the bullet in?" Microservices vs monoliths is a _tradeoff_ , and a partisan holy war "My way is right and their way is wrong" argument fails to recognize that point.

Monolithic services benefit from integration and suffer from complexity. Microservices benefit from simplicity and suffer from isolation. That's it. That's what matters. If you build a monolith, sooner or later you wind up with a big ball of mud that nobody fully understands, with careful consideration required before any new functionality or refactoring. Likewise, if you build microservices, you wind up not knowing exactly who or what is dependent on whatever mistakes you might have made in the design in the first place, and a lot of inter-team negotiation required to make significant changes in how the microservices behave.

What I find interesting is the evolution. If you have a ball of mud monolith, it can be very difficult to refactor due to complex internal dependencies. Pulling a chunk of functionality into a - microservice - is a way of pulling off a major refactoring without finding yourself up to your ass in alligators.

Likewise, if you find integration points and inter-team communication and duplicated structures are killing you, you start merging microservices together, building something more complex to solve complexities that exist outside of any single service.

Software evolves. Deal with it.

</comment><comment><USER18> We did a self-driving vehicle for the 2005 Grand Challenge as microservices. This was under QNX, a hard real time OS with really good interprocess communication. Same-CPU overhead for interprocess calls is very low, and calls over the network are also efficient.

That architecture was mostly because there were lots of things running asynchronously that were not in sync. The sensors (LIDAR, Radar, GPS, INS, wheels, etc.) all had their own clocks and schedule. An interprocess call was either "do this on your next cycle" or "what was the situation at time T"? A request for "where were we at time T" returned an interpolated value from GPS/INS fusion; T had to be at least 50ms or so in the past, so there were fixes available before and after the requested time. This allowed asking for position info more frequently than some sensors could respond. On each LIDAR line scan, the vehicle position was interpolated and used for map updating. Planning always ran a little in the past, so we could use interpolated rather than extrapolated data.

This sort of thing is common in robotics, but may not be that helpful in web services.

</comment><comment><USER19> Microservices always struck me as a reinvention of service oriented architecture from the 90s and early 2000s. This was done using RPC protocols like Java RMI or CORBA, while microservices are normally done with http(s) or event/pubsub systems.

Basically you're re-inventing linking and weak/lazy binding across a system or container boundary. That's it. This is not a new idea. It has some advantages in areas like scaling and modularity, but it also has disadvantages of increased latency, complexity, and all the weird edge case failure modes introduced by the fact that _the network is not reliable._

One of the fun things about being developer-old (over 25) is seeing the same things get reinvented over and over and over again by every new generation of developers.

<comment><USER20> I am an older dev that did a lot of "SOA" work back in the 2000's and I disagree that microservices are a "reinvention". In my opinion they are a further refinement of those SOA ideas (which is a good thing to keep moving forward as an industry).

A lot of the SOA work I did was putting REST/SOAP interfaces on various monolithic APIs. This was generally a good step forward and decoupled things (especially the front-end) but it was far from perfect. You still had the monolith and a lot of the code-smell that gets built into a monolith of spaghetti dependencies making it hard to write new features and move forward.

Now the argument is always "well if you and your team were just better coders and more disciplined that wouldn't happen" but in the real world it is shown to be incredibly difficult to actually have a team that is that disciplined and microservices give a real hard barrier to enforce that discipline.

I very rarely see things that are truly reinvented, and I think that is some serious ego bias essentially saying: back in my day we did it right and you dummies are just figuring it out.

Instead I see every new generation of developers refining good ideas over and over again which improves our industry and products.

<comment><USER21> > Now the argument is always "well if you and your team were just better > coders and more disciplined that wouldn't happen" but in the real world it > is shown to be incredibly difficult to actually have a team that is that > disciplined and microservices give a real hard barrier to enforce that > discipline.

I agree that you need enforcement. But by having a multi-module project in a good build system you can enforce decoupling at build time, without the overhead of a network bourdary.

<comment><USER20> Very true, but decoupling is only 1 of the benefits of microservice. Polygot environments, scalability, etc also come with microservices vs modules.

As with everything its about the right tool for the job and a lot of organizations are more than happy to trade network overhead for the other bullet points microservices offer.

<comment><USER21> Polyglot I've concluded is more trouble than it's worth - you always end up wanting to reuse code between modules, so a good general-purpose language for everything is much better than multiple languages. Scaling is a nice problem to have - it makes sense to split out services when you need to do so to scale, but it's not worth the overhead until you need it (particularly if you have enforced decoupling already, because that ensures that you will be able to cleanly factor out services when the time comes).

The more experience I get the more I think "right tool for the job" is bad advice. It makes it sound like tool choice is always 50-50, whereas actually in a lot of cases it's more like 95-5. I've worked at a number of organizations using various architectures, but the one that was most gung-ho for microservices was by far the least successful, I think as a direct result of their approach to microservices.

</comment></comment></comment></comment></comment><comment><USER22> Seems to me that every point is "well, it depends" and I didn't find it particularly convincing.

I work in a microservice codebase with the realization that it might have been premature to what we needed but it does roughly live up to our aspirations. Products sharing infrastructure and common functionality (accounts, file storage/management, notifications, email) and solid boundaries for easier outsourcing, support for using different languages in different parts if necessary.

I've found gains, I've found costs. The article is right in that microservices are not a silver bullet, I think few people really believe they are.

<comment><USER23> How do you handle distributed transactions?

<comment> UK-AL You don't particularly need distributed transactions if you design it right.

Generally try avoid them if you can. They have massive performance overheads.

<comment><USER23> The problem is that more often than not, you don't know the requirements beforehand.

</comment></comment></comment></comment><comment><USER24> Where did the author get those fallacies to refute? They're more like straw men.

There is no infrastructure panacea for crappy software engineering practices or bad unscalable designs.

We've been running microservices in production for years. It is more difficult to partition behavior into little chunks than to make a monolithic app. It can be slower if you don't handle inter-service RPC properly, and as your servers evolve, you have to stay on top of merging or splitting services as needed to maintain clean internal RPC's. It's a whole lot of work actually.

Why do it? Because there are also benefits. In a large system, microservices which are tested at the RPC boundary can be deployed independently of each other, which is HUGE. If you have a bunch of people building a monolithic app, you can only rev it as fast as the slowest of your teams can build and qualify it - this has been the biggest win for us! It's easier to test these things, because you can mock at RPC boundaries, versus mocking code, which is a more realistic scenario which helps you find issues like inter-RPC auth problems, which you wouldn't find in code-mocked unit tests.

I think of it this way - it's a whole lot of extra work which you have to do, which buys you flexibility in deployment and testing. That's a big deal.

</comment><comment><USER25> _You don't need to introduce a network boundary as an excuse to write better code._

This obviously _should_ be true (and for many programming languages it is) but I feel thanks to the perfect storm of Java class resolution, gratuitous use of reflection and Maven dependency rules, this isn't actually the case anymore in the Java world.

If you work on a large Java project with lots of 3rd party dependencies, you can experience some odd interactions of libraries that you'd assume should know nothing of each other - e.g. because they pull in conflicting transitive dependencies or perform classpath scanning to "simplify" configuration.

In cases like this, it's a huge help if you can keep the interactions in bound by splitting an application into several different VMs or WARs.

<comment><USER21> Java is the one ecosystem that I think has this sorted, because Maven gets releases/versioning right and makes multi-module projects easy. You need to align yourself on consistent versions of your transitive dependencies, but how many of your modules would not use most of your dependency libraries (especially the all-encompassing frameworks that tend to have transitive dependency issues) anyway? And of course all your modules have to depend on the same versions of things, but that's a good idea anyway - even in a microservice world using two different versions of a framework for different modules will lead to a confusing debugging experience. Classpath scanning would be an issue if done blindly (e.g. not scoped to specific packages), but who's actually doing that? And if you absolutely have to have multiple different versions of a dependency, OSGi, while a massive pain, is more lightweight than an actual network boundary.

<comment><USER26> Not only that, but big iron level Java app servers like OracleAS have long been able to have "hidden" dependencies. So your Hibernate dependency can depend on one version of, say, commons-lang, and your Spring dependency can depend on a different version. For many years this had to be done with tools that change the package names, but in modern app servers you can just specify this using configuration and they implement it with special class loaders. Only really causes a problem if your dependency returns instances of its dependency to callers and then your app needs a different version...

</comment></comment></comment><comment><USER27> I think the current best practice is 'monolith-first' \- but try to use a framework that allows you to isolate domains/logic (like rails engines or django apps). Then once you grow to a suitable size where it makes sense break it up.

My experience was, with a smaller shop, it was kinda hard to automate all the stuff you do when starting a new app - it may need stuff like: github repo, permissions, airbrake api key, docker hub repo, added to the CI tool, added to the static analysis tool, alerting/monitoring config, etc.

You also need a way to enforce global org requirements like, "all apps need to log in JSON so it be easily parsed later for analysis." or "all apps should expose a health check at /health-check" or "all apps need to use version X of dependency Y because of a security issue".

Without this automation your apps begin to drift in standards and practices. They accumulate old libraries and it becomes a lot harder to, say, move from one CI tool to another.

</comment><comment><USER28> Like all things in computing sometimes it works, sometimes it does not.

An example of when its a stupid idea is this:

A set of microservices for generating transcriptions for videos. It consists of the followings:

o a wrapper for ffmpeg to take a video from S3 and split the audio, put to a new s3 bucket

o A service that take the audio URL and uploads it to google STT, spits out text

Now, there is no requirement for keeping audio about, so this service is basically an unreliable single step service with poor logging and monitoring.

It doesn't help that to make it all microservice-y all the videos are shuttled about via S3. Which means they've re-created a really shit file system on top of S3.

All it needed was a hot folder, and a commandline program to be triggered by inotify.

but that wasn't new enough, despite it working and being a fucktonne faster and easier to debug.

</comment><comment><USER29> Not sure I agree with the article. In a nutshell Microservices enable the organization with rusted engineering practices to roll forward. Initially it sounds like a hype, but people will reap the benefits once they start building them.

<comment><USER4> Care to elaborate? Did you think the fallacies were straw man arguments? Logic was flawed in some of them? Did any of the fallacies ring true for you?

<comment><USER29> IMHO, I think some of the fallacies listed there are correct. Having said that, we cannot say something is bad just by the fallacies. Here are some of the advantages of Microservices :

1\. Increased Isolation / Reduced dependencies - Results in reduced code roll outs 2\. Also helps in software upgrades. For. eg. we need to upgrade from JDK (as example) from one version to another 3\. Smaller Blast radius 4\. A service can be managed by smaller team adhering to a specific service contract 5\. Forces team to do test driven development around the service contract.

Of course, every engineering pattern comes with trade offs and they may not serve all use cases. We need to pick & chose what works for the problem and team.

</comment></comment></comment><comment><USER30> I've worked with microservices in the last year and a half, and I partially agree with the author. My current approach is that of "logical microservices" \-- running within the same process/runtime, but with a language-independent API, pure JSON, for example.

</comment><comment><USER31> "When should I use microservices?"

When you _need to_.

There is a long history of applications being implemented poorly and then switching their design in order to fix the implementation. _Stop that!_ Shitty legacy codebases are a fact of life, but just changing the design without considering why it _needs_ to be that way won't result in anything more than a new shitty implementation.

At a previous employer, there was a mandate given down that all new services had to be 100% API-driven. Of course, very few people followed this. But even if they had, this would not have resulted in every single team's tools performing better or more reliably. Some head honcho probably just wanted the _potential_ for all of the benefits of services with APIs, but completely ignored the fact that there's cases where you just don't need an API, or that it would be effectively meaningless to its function.

You can design monolithic now, and split out micro-services later, or vice versa. The former allows you to work faster and get shit done now. The latter gives you the _idea_ that in the future you can tie together new services with a minimum of effort, but not a promise. Add to that that it's the equivalent of wrapping every system call in a shellack of IPC calls and you get into some really kludgy stuff. And heaven forbid you ever need to call one of those services 10,000 times more than you used to and suddenly wonder why there's a big bottleneck in your system that didn't exist when the function was monolithic.

</comment><comment><USER32> This article explains the caveats and pitfalls of microservices, which are extremely important to understand.

In fact, when making any technical decision, there are ALWAYS pros and cons to every choice. It's infuriating to me when projects, libraries, frameworks, articles, etc. only communicate their advantages without describing their disadvantages and drawbacks. I can't (and won't) pick a technology until I understand what it doesn't do and when it doesn't work.

So yeah, this is a nice antidote to the microservices hype. In my experience, these are some of the most important drawbacks of using a service oriented architecture.

</comment><comment><USER33> A problem I see with many Microservice vs Monolith discussions is that there seems to be an assumption that it is a binary relationship instead of an analog one. That is, there exists all sorts of architectures in between the microservice model and monolith model that have different trade-offs. You have programs like postfix which has a collection of small applications working together via sockets, queue based separation like sidekiq, RPC systems like protobuffers or thrift, etc. You don't have to use an HTTP/REST API to get many of the benefits of microservices while controlling the complexity.

</comment><comment><USER34> We split our monolith into microservices. We did so to make it easier to reason about but morever we did it so that we can apply different data persistence strategies for each entity. A monolith would have us bound to a single persistence type (e.g., SQL) but microservices frees us which makes reasoning the application easier. The monolith didn't work for us so we moved to microservices but we didn't start with a microservice, we started with the monolith and grew and evolved it as we needed too.

</comment><comment><USER35> This article and the points made in it looked very familiar to me.

On a related note, Martin Fowler's talk on this topic [1] has a good enough description (meaning vague, because that's what this is practically) description, the advantages, disadvantages and other nuances.

The key takeaway for me was that the team and organization have to be ready for the micro services approach.

[1]: [http://www.youtube.com/watch?v=wgdBVIX9ifA](http://www.youtube.com/watch?v=wgdBVIX9ifA)

</comment><comment><USER36> Rather than responding to each of these points, which are valid points, here's a blog post I wrote for Codeship a while back on microservices with Heroku that dives into a lot of the tradeoffs from an organizational and infrastructure standpoint.

[https://blog.codeship.com/exploring-microservices- architectu...](https://blog.codeship.com/exploring-microservices-architecture- on-heroku/)

</comment><comment><USER37> We have guidelines from long ago.. (edit: Linky here [http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s0...](http://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html) )

        Rule of Modularity: Write simple parts connected by clean interfaces.

What's simpler than a container that has clean API in and out?

        Rule of Clarity: Clarity is better than cleverness.

Container Foo does foo action. Not Bar's action.

        Rule of Composition: Design programs to be connected to other programs.

If everything's an API call, calling to it is trivial.

        Rule of Separation: Separate policy from mechanism; separate interfaces from engines.

The interfaces can be their own container. Now updating the Interface can't bring down the whole system. And the people in charge of the interface needen't have permission to change other containers (unless on that team).

        Rule of Simplicity: Design for simplicity; add complexity only where you must.

I know that a container does its job and does it well. Any complexity is contained, and cannot pollute other systems.

        Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do.

Or... The combined system that you run _is_ the big program. Because a big problem is almost always lots of small problems that look big.

        Rule of Transparency: Design for visibility to make inspection and debugging easier.

Hence the APIs. The only thing I can think of adding, is a debug tag that allows logging to a logging server if DEBUG = On. Then, it doesn't matter what server the data is climbing through; you can see it. I personally like Apache NiFi, for the provenance. There's nothing like it I've found.

        Rule of Robustness: Robustness is the child of transparency and simplicity.

A container makes it evident if it is the result of bad programming. You'll see good data go in, and bad come out.

        Rule of Representation: Fold knowledge into data so program logic can be stupid and robust.

Because you never know what the next dev will think about your code. That clever method fails if the method is deleted...

        Rule of Least Surprise: In interface design, always do the least surprising thing.

That's arguable, if you're trying to scam users with dark patterns.

        Rule of Silence: When a program has nothing surprising to say, it should say nothing.

        Rule of Repair: When you must fail, fail noisily and as soon as possible.

Absolutely. I've dealt with way too many things that fail silently, or fail with "OK", or are chatterbots on good data.

        Rule of Economy: Programmer time is expensive; conserve it in preference to machine time.

This plays right in to containerization. Compute/storage is cheap.

        Rule of Generation: Avoid hand-hacking; write programs to write programs when you can.

Yeah, LISP and FP still hasn't taken off.

        Rule of Optimization: Prototype before polishing. Get it working before you optimize it.

        Rule of Diversity: Distrust all claims for "one true way".

        Rule of Extensibility: Design for the future, because it will be here sooner than you think.

Hence containers. It's a ball of privilege separation, data segregation, clean interfaces, and easily maintainable.

<comment><USER21> > What's simpler than a container that has clean API in and out?

The problem is that network APIs still suck. The boundary between components is the place where strong typing is most vital, but microservices are still largely based around stringly-typed JSON.

> If everything's an API call, calling to it is trivial.

Calling a library API is a lot easier than calling a web API

> The interfaces can be their own container.

No they can't. That doesn't make any sense. What do you even mean?

> I know that a container does its job and does it well.

Maybe. I'm never clear on what exactly the job of the "container" is supposed to be - it seems to involve process isolation (I'd think ordinary processes should do that?), and maybe doing funky network namespacing and PID namespacing and a few other things like that, only then other people are saying you shouldn't do that?

> A container makes it evident if it is the result of bad programming. You'll > see good data go in, and bad come out.

Only if you can tell good data from bad data. Which is much easier to do within the language, where you have a type system to help you.

> This plays right in to containerization. Compute/storage is cheap.

Compute/storage is cheap, so you probably won't ever have to make your system distributed. The biggest problem with microservices is that they slow development by making it much harder to run the whole system. Anything that makes your development feedback loop slow is a big problem.

> Yeah, LISP and FP still hasn't taken off.

FP is taking off. It's a lot bigger than it was 5 or 10 years ago.

> Hence containers. It's a ball of privilege separation, data segregation, > clean interfaces, and easily maintainable.

On the contrary, containers are being pushed as the one true solution to everything, and seem to aggregate a bunch of unrelated concerns.

<comment><USER38> > The problem is that network APIs still suck. The boundary between components > is the place where strong typing is most vital, but microservices are still > largely based around stringly-typed JSON.

You don't have to use a RESTful API and JSON. If you feel that configuration is lacking you can use a binary format and a non-RESTful API.

<comment><USER21> > You don't have to use a RESTful API and JSON. If you feel that configuration > is lacking you can use a binary format and a non-RESTful API.

Sure, and that improves things a lot. I do use Thrift (via Scrooge) sometimes. I get the sense that isn't what the microservice advocates are talking about though.

But even then, why introduce a network boundary when you don't need to? All it does is make your system slower, add overhead converting back and forth from DTOs, and give more opportunity for calls to fail.

</comment></comment></comment></comment><comment><USER39> Like virtually everything else in software, it's a tool. Become familiar with it, know its advantages and disadvantages and use it when you think appropriate; always and never are probably not optimal.

</comment><comment><USER40> Microservices, IMO, are more about scaling engineering organizations than they are about scaling actual code, or producing better code. Treating each part of the product as a self-contained service (a product in itself) with well- defined customers, and defined contracts with those consumers will often allow different teams within an organization to operate with more autonomy.

</comment><comment><USER20> Some counter points, especially with fallacy #1:

 _> Fallacy #1: Cleaner Code_

 _> "You don't need to introduce a network boundary as an excuse to write better code."_

I see this all the time as the argument against microservices: "but if you are just disciplined you don't need them". It seems pretty clear to me that a large body of programming history has shown that it is incredibly difficult for a whole team to be disciplined all the time. If everyone was perfect drivers we wouldn't need seat belts. Some artificial "barriers" can be very helpful to tackle people working in the real world.

 _> Fallacy #2: It's Easier_

 _> "Distributed transactions are never easy."_

This argument I'll buy, but there is a lot of really good work going into orchestration like kubernetes which makes a lot of these concerns much lower.

 _> Fallacy #3: It's Faster_

 _> "You could gain a lot of performance in a monolith by simply applying a little extra discipline."_

Again with the discipline... But another point he makes really misses the mark:

 _> Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely_

When you have microservices it allows you to use the best tool for the job for each individual service. If you have a Java monolith and you want to add new functionality that say GoLang would be better suited for, chances are you are still going to develop it in Java because it has to fit with the rest of the monolith. His example counters his claim.

 _> Fallacy #4: Simple for Engineers_

 _> "A bunch of engineers working in isolated codebases leads to 'not my problem' syndrome."_

This is pretty subjective and I really think depends on culture and buy-in. Almost all these same things could be said about a well architected SOA monolith.

 _> Fallacy #5: Better for Scalability_

 _> "You can scale a microservice outward just as easily as you can scale a monolith."_

Again his example, seems to counter his claim. Yes you could segregate the API calls to your monolith but you are still going to have the overhead of those un-used APIs. Unless you are doing some really clever dynamic loading that code is still going to be loaded into your executable package at the very least redundantly increasing RAM load, making for wasted resource utilization (which converts to real dollar and cents in the VM world). Additionally the author completely ignores any potential start-up costs of needing to load a larger monolith over a smaller microservice.

<comment><USER41> > This argument I'll buy, but there is a lot of really good work going into > orchestration like kubernetes which makes a lot of these concerns much > lower.

Can you explain more how kubernetes help with distributed transactions? I was aware they are more of a management system for microservices, not something that handles db transactions.

I've found splitting a monolith into microservices very painful because it prevents you from easily having all-or-nothing db commit semantics. It's a lot easier to wrap your entire RPC/API endpoint in a single db transaction than it is to issue multiple commits (e.g. an RPC to a microservice that writes) and worry about the large number of states that can result if your endpoint crashes mid-way.

<comment><USER20> This was poorly worded on my part, Kubernetes does not in anyway solve this problem.

Instead I meant to use Kubernetes as an example of the work being done to standardize and abstract these _sorts_ of microservice issues. Kubernetes solves a lot of orchestration issues and I expect there will be greater work with other projects into solving other problems like distributed transactions in the future.

The current thoughts on microservices is that you should really re-evaluate how critical strong transnational guarantees really are to your application.

<comment><USER41> > The current thoughts on microservices is that you should really re-evaluate > how critical strong transnational guarantees really are to your application.

Are there some examples of what else one can do?

I'm generally fine with service 2 eventually being called if service 1 is, but then I need that to happen.

e.g. I have a payment service and an internal "subscriptions service". If user requests a refund, I have to both issue refund to payment service and cancel internal subscription

</comment></comment></comment></comment><comment><USER42> I can hear the Jet.com folks screaming right now.

<comment><USER43> Why are they screaming? Did I miss some post about them?</comment></comment>


Ask HN: Should I even bother trying to sell to universities? - <AUTHOR> I've been working on a piece of software (https://youtu.be/KwZmAgAuIkY) which is a probably too general to be a product as it is at the moment. Instead, it could be specialized in different ways to make different products—but I would like to focus on just one of these initially.
The potential products I'm trying to decide between are: (1) A multi-language 'object monitoring' utility kind of like Chrome's object explorer with certain enhancements (2) An easy to use, and very flexible instructional algorithm visualization system (3) A 'high-level' algorithm debugger.
I believe (1) has the greatest profit potential, and fewer complexities on the business side—but will take more work than the others code-wise, and I'm about out of money and need to get a job soon.
(2) wouldn't take much more work to have an alpha in order—but then I have to try selling to universities! I have no experience with this sort of thing at all. I'm unsure whether the profit potential is reasonable (i.e. whether they typically even have much money to spend; is it like Enterprise sales?), how rigid they are about adopting new software, whether they would even speak with me, or how I would initiate contact, etc.
I would use (3) personally, and it's the reason I started the project, but after sharing the idea with a bunch of other programmers, I can't see it catching on any time soon.
Any comments on which direction seems best are welcome, but I am particularly curious about what to expect if I were to follow the selling to universities route. Thanks! <comment><USER2> Whom at universities do you wish to sell to? Who do you see using this?

I work as a math professor at a state university, and overall universities don't seem like good places to work as programmers. Most of the programming- ish work seems to consist of making big pieces of software (PeopleSoft, Blackboard, etc.) work. I don't know how much actual programming this involves; I'd be a bit surprised if there was a market for your product there, but I could be wrong.

Perhaps you instead envisioned working with individual CS professors or departments? There your prospects are probably better; if you persuade someone there that your software is worth buying, they might well be willing to buy at a couple thousand dollars. They have their own (smaller) pots of money which they control and would not need to fool around with much bureaucracy to buy.

The disadvantage is that it would be hard to get your foot in the door. Contact information for professors is easy to find, which means that people are constantly contacting them with all sorts of unsolicited requests, and their fingers are used to finding the `D' key quite rapidly. If you somehow got a couple of individual, influential CS professors to use and love their product, they might recommend it to their peers. This could be difficult though ... for example, in six years of working as a math professor I have not yet purchased any software, although I could if I wanted to.

There are smart people in academia, doing interesting and worthwhile things -- but I expect that it would be an exasperating market to sell to. Good luck if you try!

<comment><AUTHOR> > Whom at universities do you wish to sell to? Who do you see using this?

I see it being used as a pedagogical aid for professors. I've run into some research demonstrating the efficacy of these kinds of visualizations for CS education, but their conclusion was that they are too expensive to produce. I make them cheaper by providing a general purpose platform for algorithm visualization, where you get visualizations just by writing the code like you normally do.

> but I expect that it would be an exasperating market to sell to.

That's kinda what I was thinking :/ I'll try to get some more data since this post didn't really take off—but it looks like I'll probably try a different direction to begin with...

Thanks for the info.!

<comment><USER2> > I see it being used as a pedagogical aid for professors.

This is, unfortunately, likely to be difficult.

The pots of money that professors typically have at their discretion is usually for research, and comes from grant funding (e.g. the National Science Foundation). Although most professors do care about teaching, they aren't likely to spend much in this instance.

Wish it weren't so, but that's how the incentives typically line up. I hope I'm wrong!

</comment></comment></comment><comment><USER3> Can we have more details on (3)? Sounds like something I'd use for sure from the video/high level description...

<comment><AUTHOR> Actually, I have another video and more written description on it here: [http://westoncb.com/projects/avd](http://westoncb.com/projects/avd)

That material is quite a bit older, but that's when I was focusing more on (3), so hopefully it clarifies things.

The main idea though is: when you're inventing a new algorithm to do something, you're typically thinking in terms of operations on data structures, rather than something lower level like lines of code in a particular language. So, if you use this tool while attempting to write your new algorithm, it will give you a visualization of what your code is _actually_ doing to the data structures involved, versus what you thought it was doing.

</comment></comment><comment><USER4> Awesome stuff</comment>


TV Will Be Apple's Undoing - <AUTHOR> http://online.wsj.com/article_email/SB10000872396390444813104578018301108074448-lMyQjAxMTAyMDIwNjAyODY3Wj.html <comment><USER2> From Fortune: "This is not the first time Jenkins has peered into Cupertino's future and foreseen doom. Two years ago, in a column entitled "The Microsofting of Apple?", he excoriated Apple for rolling out "increasingly junky devices" (referring to the iPad) and for making a strategic decision to "cut off its users from a huge amount of Web content" (referring to mobile Flash).

Since Jenkins wrote that, Adobe (ADBE) has conceded that mobile Flash doesn't work and Apple has sold more than 100 million of those junky iPads."

</comment><comment><USER3> I have a strong suspicion this guy is just pontificating without actually having spent any time with people in big content.

> _Video-content owners aren't looking for a savior and ultimately won't be > satisfied with anything less than an open ecosystem accessible by any > device._

Big content doesn't give a _fuck_ about open ecosystems. They care about cash money and to a lesser extent they care about control. What they don't want is a Netflix decimating and dominating the market. They may be wary of Apple because of their dominance in iTunes, but if they can grow the market (which their app store model seems like it has a shot) then big content is happy to play ball with them.

<comment><USER4> I've worked in the TV (set top box) business. Oh, god.

The cable companies (a) despise their customers, (b) hate to innovate, and (c) their /short term vision/ is on the order of five years.

Cable Labs? A firewall against companies that think they can intrude on the space. Want to do something new and whizzy? No problem, just pass some compliance tests . . . which takes months or years.

Also: TV is harder than you think. Think "legacy network with some interesting regulation thrown in" (e.g., handling emergency broadcast signals, batshit insane limits on use of bandwidth) and that's for starters. Comcast's back ends are running horrible software stacks, and interoperability with that stuff is really hard; you get to build your own back-end for testing, probably millions of dollars . . . and then you get to integrate with Time Warner's stuff, which is all different, and Rogers, and so on.

TV is all about smiling people circling each other with knives. It's full of entrenched players who are happy to screw anyone, including big companies who think they can do end-runs around carefully erected defenses. TV is war.

<comment><USER5> > Also: TV is harder than you think. Think "legacy network with some > interesting regulation thrown in" (e.g., handling emergency broadcast > signals, batshit insane limits on use of bandwidth) and that's for starters.

Well fuck that. Just do it all over the internet. The ideal system would be one where you don't purchase channel subscriptions, but individual shows. Then you can watch the shows you've purchased as many times as you want, on any devices you own. Of course, you will get "live" broadcasts in the form of being able to play it live when it normally airs for the first time on TV.

This is exactly what Apple's vision is, and I hope they find a way to make it happen, but I'm not very optimistic.

<comment><USER4> Again, it's harder than you think.

\- You have to get content. Those people want to be paid. You are in competition for this.

\- The cable companies control your air supply -- the bandwidth to your customers -- and unless you make them happy, your customers are screwed if they watch your stuff. Bandwidth caps on the order of 25GB / month are just crazy small for any amount of TV watching.

Apple could probably afford to buy Comcast (and Warner). That would suddenly be interesting.

<comment><USER5> > Again, it's harder than you think.

That's why I said I'm not optimistic. I have the confidence that Apple can do an excellent job of creating a solid and intuitive UI and service. I have very little confidence that they will be able to make the sort of content deals necessary to make it have practical value.

I don't think the bandwidth caps are a big issue, because 720p video is probably 1 GB/hour. You would have to watch 8 hours/day to hit a 250 GB limit.

</comment></comment></comment></comment></comment><comment><USER6> I have to wonder how much research the author actually did:

> _Video-content owners, including...the NFL and Major League > Baseball...aren't looking for a savior and ultimately won't be satisfied > with anything less than an open ecosystem accessible by any device._

Well, MLB is already on the Apple TV, along with the NHL and the NBA.

> _Apple's rejection of Google's superior maps is an obvious example, but it > goes with the turf. Apple's spectacular success with devices naturally led > to the temptation of a network-effects empire. To such empires, maps are > just too important as a way to gather information about users and hit them > with ads and e-commerce opportunities._

Does _anyone else_ really believe that Apple switched from Google maps because they want to build a "network-effects empire" in order to show people more ads? Google is in the ad business; Apple is in the selling-you-devices business.

> _Let it be said that some techies see evidence of a more rational impulse > within Apple. They say Apple's browser and HTML5 support are conspicuously > superior to Android's. Within Apple apparently there are teams committed to > making sure Apple devices are competitive in the open-ecosystem world that > is coming._

This...I don't even know. Steve Jobs _himself_ said (albeit in relation to Flash) "New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too)."

Apple won't come undone because their TV doesn't sell; Apple will come undone when competitors can consistently make markedly better products.

<comment><USER7> > _Apple's rejection of Google's superior maps is an obvious example_

Also, they never "rejected" Google's maps. They simply chose not to distribute it as a default app anymore and now Google has not yet gotten their new Map App ready.

Just one of the many examples where the author clearly twists and distorts reality in the article to fit into a very loose chain of arguments.

</comment></comment><comment><USER8> I thought iPod HiFi was their undoing!

They've had so many, it's hard to keep track.

My instinct is that the TV is a stalking horse. Zero doubt that they're working on something, and it looks like a TV, but it has to be something a whole lot more than iTunes+flatscreen+Siri. I know what _I'm_ hoping for...

But if I'm wrong, or if it fails, or both...it will hardly be Apple's undoing. Their most profitable product lines are still growing fast, and the others are doing respectably well. They'll need a new product line in the next few years to maintain growth, yes, and there are other threats. I'm not worried about this one.

</comment><comment><USER9> _Simply, content is king again._

I really don't like the dichotomous 'X is king'/'X will lose the war' mindset - it's lazy and it leads to sloppy thinking and bad decisions. Yes, content is important, but so is infrastructure, and execution, and ease of use, and so on. In fact if I were to come up with a single reason for Apple's success, it's that they understand this - they do the hardware, AND the software, AND the online ecosystem. Apple doesn't do hardware or software per se - they do SYSTEMS.

Nobody has got the Internet/TV meld right yet. Seen a Google TV recently? Certainly it will be tough for Apple to get it right, but dismissing them like this is just nonsense.

<comment><USER10> >Nobody has got the Internet/TV meld right yet.

Umm, xbox?

<comment><USER11> Maybe it's different in the US, but in Europe, the Xbox is basically just a gamer thing. Many people who play games on their iDevices and maybe even a Wii wouldn't even consider buying an Xbox - the branding/marketing/positioning tells them it's just not for them. Also I think the content situation for streaming in Europe is a mess, so most people still watch DVDs or satellite pay-TV or cable (with set-top-box lock-in). That said, if Microsoft released a rebranded Xbox (not using the Xbox brand) as a pure media device (and sorted out the content issue), they might be on to something.

<comment><USER12> I think something like YouView has the most potential. It needs a few more years of development, but it could be bundled into TVs and resold to broadcasters in other countries as a state broadcasting standard.

<comment><USER13> Not going to happen (bundling into TVs and being resold to other countries).

Firstly it is not a standard in any meaningful sense but a platform that happens to be owned by the main free channels and the telcos. It's actually a bit like Android except Youview can push updates without even the manufacturers approval!

The rest of Europe has adopted HBBTV as a standard already and much of the world is adopting similar HTML based solutions if not HBBTV itself.

As it currently stands a hard disk is required and that is unlikely to be bundled into many TVs in the near future. Spinning rust is too bulky, it adds cost. Flash is too expensive still for the Youview minimum of 250MB (or is it even more than that).

For the major TV manufacturers the loss of control of the TV UI is a major issue and they are unlikely to do that unless they really have to. For the UK alone it is very unlikely. I'm surprised that some have gone the GoogleTV route to be honest but I think they were imagining it would take off like Android has. Also going the Youview route removes their potential revenues from operating their on online platforms.

So for the above reasons Youview as it currently stands will not make any impact outside the UK (and it won't actually make much inside either) and won't make a major part of any TV manufacturers line up.

</comment></comment></comment></comment></comment><comment><USER14> My favorite quote:

"A similar miscalculation led Microsoft to treat Netscape as a mortal threat and into a self-defeating tussle with a reciprocally purblind Justice Department. The Web did indeed create enormous opportunities that were seized by companies other than Microsoft, but Microsoft is still around and doing fine."

That is some serious revisionist history going on there. The author seems to forget that Netscape was a huge threat to Microsoft. Microsoft then shifted their strategy to focus on the web in, what I would argue, is one of the more impressive pivots by a large company. That pivot led to Internet Explorer crushing Netscape and becoming the number 1 browser. It also led to a radical reinvention of the Microsoft developer toolset to focus on the web - ASP, ASP.NET, etc. These technologies may now be passe, but they were pretty cutting edge at the time. And even though Microsoft has now, in my opinion, fallen really far behind in the world (missing most of mobile, etc), you can't say that it was a miscalculation to go after Netscape - think of where they'd be if they'd not gone after them.

<comment><USER15> I feel the only reason that Netscape was considered a threat by Microsoft was because Microsoft made them into a threat to be dominated and crushed. It's true that Netscape was working on things that could have potentially lowered the value of the OS market but that wasn't just Microsoft's sole source of revenue. Unless Netscape released products that totally replaced Microsoft's line of software then people, especially businesses, were going to continue purchasing Windows.

You are quite correct it was a hugely impressive pivot for Microsoft, even though they claimed there was no such pivot since the web was part of the plan. Funny that Win95 didn't initially ship with a browser nor did it install TCP/IP by default but they tried to convince people that it was a "web OS" from the beginning. Then they did their typical thing for the time; create a browser that they eventually released for free, then make it required for Windows, start duplicating other Netscape products to undercut them, and then claim it was their intention from the beginning the whole time. Netscape's demise was just a natural outcome of their superior planning and execution. The Dept of Justice eventually disagreed with them but Netscape was already dead in the water by then.

Now, considering that the result of all this was the era of IE6 that we are just now starting to get out of over 10 years later, I would say that the Internet would have been better off without their pivot. Granted the tools you mentioned are nice but there's no reason to think that Netscape, or someone else, wouldn't have done similar things and possibly better since they most likely wouldn't have tied them to a specific OS. These days hardly anyone makes web tools tied to one OS, mostly Microsoft does that.

As for Microsoft, where would they be today if they hadn't crushed Netscape? I would say that, because of the competition, they would have made better products and be stronger overall. Once they crushed Netscape they stagnated a great deal that eventually caused them to fall behind, as you point out. Their complacency allowed others to step in to become serious competitors that finally resulted in the web tools you mentioned.

I would even say that because of them crushing Netscape with tactics, used elsewhere as well, that resulted in huge problems with governments around the world caused them to be reluctant to be aggressive; which resulted in them missing the mobile window. They are just now seriously trying to get into that game.

Of course, most of this is based on hindsight, which is easy to comment on.

</comment></comment><comment><USER13> He isn't completely wrong...

TV won't be Apple's undoing but it also isn't obvious that they can win big there.

It is a complicated business with a number of interlocking players at different levels and vested business interests. It is also a global business with rights packaged up at a very national level and sold with exclusive deals.

While the biggest MSO's in each country (cable, satellite and terrestrial operators depending on the market) have the scale to lock in key content/channels to exclusive deals it will be fairly hard to break into the market in a devastating way. At the moment they have the scale and the revenues to do exclusive deals with the content creators (that they don't already own) to keep a large proportion of their customers from leaving. They (not the content creators/owners) are the big bullies in the market and would be hard and expensive to topple.

An AppleTV (including screen) if it does happen will need to be a good enough content offer for most people or it will not be a massive success. If they still have to use their cable box it can't be a game changing user interface because you are looking at the STB interface most of the time.

It's not impossible for Apple but it also won't be easy, particularly to go global. It will cost money to get content which might break Apple's principles and set a bad precedents for them. They also can't go that expensive because while I'm sure the UI will be better Samsung/Sony and some of the others really aren't that bad and the cosmetic designs don't leave that much room for minimalist improvement.

The business case for Apple is far from clear for me at this point but it would be a way to take the war to Samsung that would cost Samsung far more than a billion dollars even for an Apple relative flop. The collateral damage might kill Sharp unless they supplied the panels and would be another knife in Sony/Panasonic/Toshiba that they could do without.

<comment><USER16> > _TV won't be Apple's undoing but it also isn't obvious that they can win big > there. It is a complicated business with a number of interlocking players at > different levels and vested business interests. It is also a global business > with rights packaged up at a very national level and sold with exclusive > deals._

Funny, the said the exact same thing about mobile...

<comment><USER13> Nearly true but I think the situations are really different - the rights packaged up and sold with exclusive deals didn't apply in a relevant way and there wasn't the same level of complexity.

Carriers were essentially indistinguishable from a customer viewpoint. There was no significantly different content depending on which carrier you used or at least nothing that you would care about if you had an iPhone. This does not apply between broadcast platforms. The exclusive deals any carriers had for content were small scale apps or information services not multi-billion deals for packages of content for particular countries.

Apple played divide and rule between the carriers brilliantly working with a single operator in each country. In some countries that might work for TV where there are well balanced alternative platforms but in others it won't work because there is a dominant player who won't give up control and the challengers are too weak to help Apple much.

In TV there are the content originators (movie studios, sports leagues, independent production companies), one level of aggregators that commission and purchase from the originators and bundle it into channels and another level of aggregation by the service/delivery/billing platforms (MSOs). And then it is sold to the customer. These divisions are not clear and ownerships ofter cross levels.

In mobile it was fairly simple with carriers being the clear centre of the business, buying and subsidising phones and running the infrastructure. There were a couple of platforms running across different phones such as BREW and JavaME but they were more feature tickboxes than major market players.

This doesn't mean it was easy for Apple but the fact they had at the time a truly revolutionary product and reality distorting leader AND there was level competition between the carriers meant that they could pull off an amazing industry changing deal. They had to pull off this deal once in each country not with dozens of different rights holding players (they don't need them all but one deal per country would only be enough with the dominant MSO and probably wouldn't be on good terms as the MSO would know that there is a risk that Apple would want to cut them out when they were big enough).

I also didn't say that it was impossible for Apple to break into the TV market in a massive way but I certainly don't think it is easy or that there is a clear route to massive success. I certainly don't believe it is possible at their current margin levels for either hardware or content but it will be interesting to watch.

I used to do what was really a Business Development and Product Planning role for Sony's European TV Business so I have met with many cable, and a few terrestrial and satellite operators in Europe to persuade them to make their content available over their networks to consumers TVs with CI+ (think European CableCard but not quite such a broken model). Later I worked with many channel operators to bring them onto Sony's Internet TV platform so I do have some understanding of the TV business.

</comment></comment></comment><comment><USER17> Rubbish.

> Video-content owners aren't looking for a savior and ultimately won't be > satisfied with anything less than an open ecosystem accessible by any > device.

If they wanted an open ecosystem, they could have had it years ago. _It's called the web. You might have heard of it._

Did the networks see Youtube and say, "oh, we could have people pay to log in to a web site and watch TV! It would work on any web-capable device anywhere in the world! Hooray!"

Heck no, they didn't. They don't want an _open_ ecosystem, they want one that _they_ control. Rather than build one that satisfies consumers, they've tried to destroy or control anyone else who builds one.

This is _not_ about openness; it's about _control_.

> Television is about to demonstrate the inadequacy of Apple's own business > model.

Doesn't that sound a bit gloating?

> How TV content owners in the future will get paid is but the flip side of > the question of how pipe providers will get paid.

This doesn't even make sense. We already know how "pipe providers" get paid: ISPs get paid by customers and peering agreements, and content providers get paid by viewers and listeners. The end.

What's holding up the future is not Apple or Netflix or Google; it's content providers who want to keep getting paid for channels nobody watches, distributed and restricted under complex international agreements, when they could just offer _on-demand content, for money, over IP, to anyone in the world._

> Expect the TV and broadband businesses both to reorganize themselves almost > overnight.

You mean like, "hey, your cable TV is now an internet connection, so just click the programs you want to see. The bandwidth we used to spend sending 100 channels while you only watched one is enough to send the 1 show you actually want in higher resolution. Enjoy!"

I guess they'll do that overnight as soon as the internet gets invented.

</comment><comment><USER18> Apple are already the largest company in the world, and they don't have TV. Its not like they're _losing_ anything, so even if they don't "win" TV I don't se how it spells their demise.

</comment><comment><USER19> Well, the author has some strange views at the best of times, but not understanding the subject you're writing about is mighty tricky.

Apple sells content for it's devices, Amazon sells devices for it's content. In the content marketplace Apple has significantly less invested than Amazon, so really the article would be better suited there. And it'd still be a terrible article.

</comment><comment><USER20> I don't own a TV so maybe I'm not the best person to comment, but my feeling is that even though most modern TVs are filled with features, few people actually use them.

Apple might do pretty well by just bringing to market an easy to navigate device which would enable people to easily buy content from the networks (or whoever owns the content). Just like we do on iPad.

</comment><comment><USER21> Apple succeeded in music because music was already pretty beaten down by piracy when Apple approached them with iTunes.

The same strategy won't work with TV because they saw the piracy danger coming and made serious efforts to squash it and continue to do so before it threatens their business model. They're sitting on a much strong position and are unlikely to offer Apple favorable terms for distribution.

The way I see it, the only way to disrupt TV now is to build an alternate production model in addition to utilizing new consumption models. I'm hoping Netflix will see success with its original content and pave the way for other companies, like Apple, to follow suit.

<comment><USER15> I've seen no indications that the TV and movie industries have been more successful than the music industry in stopping piracy. The only thing that slows video piracy is access to bandwidth.

<comment><USER21> I would argue that major content providers like Comcast and Time Warner have done a lot to keep us from having access to bandwidth or imposing data caps even when they provide the speed with their cable internet providers.

</comment></comment></comment><comment><USER22> >They say Apple's browser and HTML5 support are conspicuously superior to Android's.

Not even remotely true for anyone who's used ICS. And it's not "Apple's browser" it's the rendering engine from the KDE(GNU) world which Apple improved, and Google improved just as much. Safari is so overrated it's not even slightly funny. Chrome, Firefox and Opera are light-years ahead of Safari.

</comment><comment><USER23> > _Let it be said that some techies see evidence of a more rational impulse > within Apple. They say Apple's browser and HTML5 support are conspicuously > superior to Android's. Within Apple apparently there are teams committed to > making sure Apple devices are competitive in the open-ecosystem world that > is coming._

Huh?

</comment><comment><USER24> I can't believe how a 40" ipad with an apple tv stuck in the back with krazy- glue won't sell ten million units in its first xmas.</comment>


Adeo Ressi: How To Perfect The One Sentence Pitch - <AUTHOR> http://techcrunch.com/2010/11/03/madlibs-pitch-adeo-ressi-founder-institute/

<comment><USER2> My Company, Anybots is developing a video conferencing robot to help remote employees of mid-sized companies stay in touch with the main office more effectively.

Also "parents who are female"? if only there was a short english word to replace that wordy noun phrase.

<comment><USER3> I'm pretty sure you're being facetious but moms? Lol

</comment></comment><comment><USER4> My company, Startup Garage, is developing a web based social tool to help people with an idea get started, get going and get ready to launch their startup using techniques from games, the customer development process and social pressure when you have more passion than funding and haven't quit your day job yet.

Phew. That's a long sentence.

EDIT: Basically, we're a virtual pre-incubator. That's at least a much shorter sentence.

<comment><USER3> Too long, tighten it up.

How about?

My company, Startup Garage is developing a Facebook application to help entrepreneurs overcome their lack of motivation by providing social pressure to execute.

If the people already have a job, have you considered doing something similar to app sumo to sell them services? If they have a day job they have disposable income, but not capital.

</comment></comment><comment><USER5> My company, stealth web-scale database company, is developing a web-scale database to help web-scale companies solve their problems with web-scale data... our secret sauce is our web-scale database.

</comment><comment><USER6> My company, Crossies.com is developing a media marketplace to help consumers find and buy music and movies at low prices, and let them sell media they own when they are done with it.</comment>


A small town that kept Walmart out now faces Amazon - <AUTHOR> https://www.theatlantic.com/business/archive/2018/03/amazon-local-retail/554681/?single_page=true <comment><USER2> I live 10 miles from the town featured in this article and its publication has caused quite a few folks I know around here to renew their effort to buy local. To me though the frustrating thing is this line in the article:

> I twice stopped by Wilson's, the department store, to try to meet the > manager, and saw no shoppers inside the store the entire time I was there. > (Wilson's did not respond to multiple interview requests for this story.)

With a switch in marketing Wilson's could become a destination store as going in feels truly like going back in time. It's a real department store with separate registers in each department staffed by folks who know about what they are selling. Wilson's still puts huge full page ads in the local paper but I've never seen a single online or social marketing message from them. If/when they go out of business it is going to put a huge hole in the fabric of downtown Greenfield.

<comment><USER3> _its publication has caused quite a few folks I know around here to renew their effort to buy local_

"Buying local" is the kind of thing everyone is in favor of and no one actually does. Well, okay, not "no one," but far fewer than favor it in theory. Like "giving up Facebook," "switching to Linux" and "always using a condom," the number of people who make the claim in order to signal something about themselves is much smaller than the number actually engaging a behavior.

See further Seth Stephens-Davidowitz, _Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are_ ( [https://www.amazon.com/Everybody-Lies-Internet-About- Really/...](https://www.amazon.com/Everybody-Lies-Internet-About- Really/dp/0062390856?ie=UTF8&tag=thstsst-20&linkCode=as2&camp=1789&creative=390957) ).

<comment><USER4> >"switching to Linux"

Been using Ubuntu for close to 5 years now. I tried, I really tried to love it but the drivers are horribly outdated. Nvidia graphics broke everything in my Dell 9560. Even a fresh install of Ubuntu LTS is practically unusable. Each keystroke takes around 3 to 7 seconds to register. The screen lag is horrible. I tried fresh install and still everything looks pathetic compared to OSX or even Windows 10.

After Windows 10 got native Ubuntu 16, I just moved to it and though I have to run Linux startup services manually I am pretty satisfied with it.

We can't fight the inevitable just because of personal vendetta. Walmart was a small time store once. They got big because of the ease of use. Same with Amazon. To me it's just stupid to go out of the way to "buy local" when it's a losing game.

<comment><USER5> I've also earnestly tried switching to Linux many times, over 15 years. My most recent attempt was just a month ago, after becoming infuriated by Windows Update.

It's not terrible, but taking all of my daily work into account, it's still not feasible on the whole. And the problems are about the same as always. Hardware compatibility, arduous installations and config (yak shaving), and stuff just not working. And the pervasive pattern, inherited from open source itself, that things have recursive dependencies, each involving their own incredible journey of configuration and workarounds. Always the journey, never the destination of getting work done. In the end, I clean installed Windows, set it up to minimize annoyance, and got on with work.

I feel that, much like Blender, Linux requires a certain mindset. I suspect that mindset resembles either masochism or Stockholm Syndrome. I still have no complaints about MacOS.

<comment><USER6> Linux runs fine on desktop. I haven't had a significant issue in years on hardware that has the benefit of reliable wall power.

<comment><USER5> That's good to know. It's true my last attempt was on a low end laptop. My qualms about my daily applications remain. I'm sure I'll keep trying.

<comment><USER7> Linux SysAdmin here with 20 years' experience: I love it on the server and hate it on the desktop. Always use the right tool for the job.

But that's a good analogy for this article. UNIX-like devices did eventually dominate the world, just not in the form factor we were expecting. I'm writing this on my pocketable UNIX device. You've probably heard of it; it's called an iPhone. If one adds up all the devices in the world, Microsoft only owns a fraction of all of the operating systems installed.[1] Like the store keepers in this article, Microsoft failed to adapt but continued to rely on an increasingly failing business model (desktops). There will still be a place for Windows in 20 years but it will be a niche product like macOS is today. Unless they quickly adapt.

I certainly prefer to Amazon something than go to a store. This story is one of struggling to protect a failing business model. Were I one of those business owners I would spend all of my (increasingly) free time learning to either sell online or tweak my service so that it's so compelling that people would willingly dress, drive out, risk crowds, and pay more. I would get online (hah!) and find the world's best retailers, find out what they're doing, and emulate their success.

There are still buggy whip manufacturers[2] but they learned what was needed to adapt. Adapt or get run over.

[1] [https://en.m.wikipedia.org/wiki/Usage_share_of_operating_sys...](https://en.m.wikipedia.org/wiki/Usage_share_of_operating_systems#)

[2] [https://www.uswhip.com/product/buggy- whips/](https://www.uswhip.com/product/buggy-whips/)

<comment><USER4> > I love it on the server and hate it on the desktop

It's an equal nightmare to develop on windows and deploy on Linux. But it's true. I have Linux systems running for couple of years with no downtime at all.

<comment><USER7> Not even for kernel updates?

<comment><USER4> Yes it requires an restart for kernel but for one machine I never did for an year

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> > _Online retail—including selling through Amazon—has helped him keep the > doors open. (He bemoans the fees he has to pay Amazon for the privilege, > however.) He estimates that half of his revenue comes from online sales; the > other half is a mix of in-store transactions and pop-up sales he does in > busy locations like downtown Boston. "I go where the customers are," he told > me. But his Greenfield location produces only a small part of his > revenues—if he makes $50 in a day in his store, it's a good day, he said._

$50 a day at a brick-and-mortar location? That sounds unsustainable, I wonder why even bother keeping it open? Does it help his branding/online reputation?

<comment><USER9> It's probably also the warehouse for his inventory (or at least it should be)

<comment><USER10> There are some cities that consider warehouses "Industrial" zoning and retail as "Commercial". Keeping a storefront could help you stay in a commercially zoned area if you prefer it for some reason.

<comment><USER11> To add to your comment, many if not most municipalities tax industrial buildings at a higher rate than they do commercial buildings. This could indeed be a nice tax saving strategy for the business.

</comment></comment></comment></comment><comment><USER12> There were articles related to this on how shopping and branding is shifting:

(1) An article about an Independent Bike Vendor that shifted its business model to an Independent Bike Services. They make their money primarily from servicing bikes, making recommendations. Releasing pressure from having to make their most revenue from selling bikes allows them to make the best recommendation for the biker. Bikers who buy direct from manufacturers will still want an expert to service their bikes.

(2) An article about Nike and some of the major brands shifting to a different business model where in-store shops are no longer _distribution_ channels but rather _marketing_ channels. These shops provide an in-person experience. They are paid by the overall revenue for the brand rather than what gets sold through the store. This aligns the incentive structure to what consumers are now doing: trying them on in a local store and then buying them online.

Where do small business owners fall into this? I don't know. Bikers and commuters tend to have a lot of attachment and affection for their bikes, and are willing to pay for services. Clothing in a department store, perhaps, not so much. Books? Toys?

</comment><comment><USER13> I wonder if internet shopping will one day help small towns rather than hurt them. One of the things that really sucks about living in small towns is that its difficult to buy the stuff you really want due to limited products available. When small town residents have access to unlimited ranges of goods and services at cheapest prices, its one less reason to travel to, or even move to the nearest city.

<comment><USER14> That problem was already solved by catalog and QVC.

The problems in rural areas stem from lack of new job growth since 2008 implosion, and jobs with poor wages (and not enough of these even). Not gonna help people buy much online.

Logistics around literal access aren't the issue. It's the same old tune: financial access.

Putting a website up in place of a catalog doesn't solve that problem.

<comment><USER15> > That problem was already solved by catalog and QVC.

This is like saying that playing video games over the internet is nothing new, because hey, people already played games over distance in the form of chess by mail.

<comment><USER16> Playing video games over the internet is nothing new, because hey, people been doing it for decades.

</comment></comment></comment></comment><comment><USER17> > How might local businesses respond?

1\. Convenience. I used to stop at a local toy store on the way to a birthday party, or the day before, to buy a wrapped present. They closed, so now I drive ~15min each way to the next closest toy store.

2\. How do I know what local stores have unless I go there and ask? I'd like an app that would allow me to comparison shop across Amazon/Target/Walmart/local stores. Let me know if you want to work on that with me, sounds interesting.

3\. Add value - online reviews are sometimes useful, honest expert advice is great.

<comment><USER18> 4\. Price match. This can be a double-edged sword and it may be unsustainable but if I'm the shop owner I'd lose a bit of margin rather than the entire sale. As a customer, who wouldn't want the item now vs. waiting 1-5 days for it.

<comment><USER19> a reason they can't price match is that their prices are already at razor thin margin, since their economy of scale doesn't kick in like the big co's.

</comment></comment></comment><comment> X-Istence I'd shop local more often, if only it weren't for the shopkeepers always intruding on my thoughts and thinking by asking if I need anything.

Not having to interact with other humans beings is the best thing about online shopping.

<comment><USER20> That's a benefit of shopping in a brick and mortar store! I used to always get annoyed and say "no thanks, I'm good" when the employee approached and asked that question, but then a friend told me that I should take their help. If you tell the employee what you are looking for, or that you don't know exactly what you are looking for, they will usually (about 75% in my experience) be very helpful. The employees tend to be very knowledgeable about what they are selling and have good advice about what to buy or what not to buy.

<comment><USER21> > The employees tend to be very knowledgeable about what they are selling

That's often true of specialty stores, especially independent local ones. It's often not true of big chains and stores that don't have a narrow focus.

It's also often the case that they will steer you based on their knowledge of their sales incentive structure, which is often _much_ better than their knowledge of product.

<comment><USER22> Yep, best example: car dealership.

</comment></comment></comment></comment><comment><USER23> Ultimately, if you're a business that isn't providing what people want at a price they're willing to pay, you're not going to stay in business. I don't know that there is anything to fix here, other than making sure that the people that depend on places like this for work get a soft landing and help finding new work.

<comment><USER24> IDK man. "Free market will decide" is great, but the issue is becoming that the free market has decided that low wage, non-skilled jobs are low hanging fruit to cut. Replace someone with a kiosk or a robot or just outsource the whole store to an online location and a warehouse/shipping department.

The biggest issue with these sort of stories are that there are these Neo- Luddites who think that we can keep/make jobs in the face of online retailers killing many types of work. Giant corporations don't hire the same number of people that they used to, and the people they do hire don't tend to be low skill positions.

Retail is dying by inches, but it's dying. People can make "customer service" a rallying cry, but "customer convenience" seems to be the actual metric that matters. We're getting rid of these jobs, and too often we're either not replacing them or we're dealing with people who were in _JOB X_ for 10+ years and are unwilling/unable to change to a new field.

I'm not saying any of this is "bad", just that "soft landing and help finding new work" is a cute dream, but not likely. This is what disruption does. It ruins the current paradigm.

<comment><USER25> So it turns out that "customer service" is actually a good in and of itself that has a price and needs customers willing to pay that price. A Walmart shopper is typically not willing or able to trade some of their disposable income for a more knowledgable/helpful employee. There is a reason that Trader Joes, Whole Foods, and Walmart pick the inventory mix they have, where they locate, and who they hire. They are all different business models with different customer groups.

People with less disposable income have increasingly prioritized physical products over paying for any meaningful interaction with employees which is fine. It is their choice to do so. If people actually value having meaningful interactions on main street in small town America they will still have them. But I suspect that most people don't value that, which one could argue I suppose is bad, but it should ultimately be left up to the individuals that live in small town Vermont, not me.

I rely on a couple of small businesses near me, one of which is my butcher. One might say well the butcher is an unskilled job, but he is selling me two things. First is better meat than Whole Foods. Secondly he is quite a good cook so he can recommend cooking techniques or I can say "I want to do the brisket sous vide" and he will trim it so just the right amount of fat is on it. Obviously this works better with organic products rather than something made of plastic where everything in the same box is a perfect substitute.

<comment><USER26> Not to disagree with anything else you wrote, but anyone who says butchery is an unskilled job has definitely never tried it. What other C21st job has a legitimate need for chain mail?

<comment><USER25> I don't think butchers are unskilled, but I have run across people who do. Having an actual butcher has made me a better book :-)

</comment></comment></comment></comment></comment><comment><USER27> In a lot of ways, they brought this on themselves. Small, local businesses don't have the selection or the prices that large national stores have.

In the end, it's going to be Walmart or Amazon. Walmart will at least hire local people to staff the stores, and local stores might be able to survive as ultra-niche places that will carry all the oddball "long tail" stuff Walmart won't bother with. But if you don't let the population have a nearby store that has good prices, good customer service, and a good selection of the things the bulk of the population wants, they'll go online for it, they'll discover that Amazon actually does have everything (well, except for a Chromecast or a Nest), and the nearest fulfillment center will be too far away to hire anybody local (I say "will" rather than "may", because if they're keeping out Walmart, they'll keep out Amazon fulfillment centers too).

And let's not just talk about the selection and the prices. Let's talk about customer service. Big companies prioritize the bottom line, so the last thing they want to do is turn away customers or risk a black eye on social media that can spur a boycott. Small businesses tend to take an attitude of "I'll run my business _my_ way, even if it hurts the bottom line!". Case in point: Macy's has fired multiple employees for telling trans women that they're not allowed to use the ladies' fitting rooms. They have a corporate policy of non- discrimination, and employees who break that policy get canned. Why? Because turning away customers is bad for business, and the last thing they want is for "boycott Macy's for transphobia" to trend on Twitter. A small businesses may very well take the attitude of "I'm not treating you freaks like women, so get out!", they're willing to lose the business for the sake of their principles, and they're not going to face much backlash in a conservative small town. Or you see all the cake bakers who refuse to bake for LGBT people; you won't see that kind of discrimination at Kroger. I am 100% fine with these small businesses going away. They actively make life worse for marginalized people like the LGBT community (I'm a lesbian trans woman myself), so I'll do whatever it takes to accelerate that process and replace them with bigcorps.

And let's not just talk about how small businesses are worse for the customer. Let's talk about how they treat their own employees. Laws requiring employers to provide insurance benefits to their employees don't kick in unless the employer is over a certain size. And it's precisely because of small businesses that the US doesn't have as many employee-friendly laws: it's the small businesses, not the big corporations, who are terrified of the government mandating that employers provide large amounts of vacation time or comprehensive health coverage. Big businesses are big enough to soak the cost; mom-and-pops aren't. And it's not just about benefits: think also what HR departments can do for you. If you work at Walmart, and your supervisor is sexually harassing you, you can file a complaint with HR. If you work at a local shop... your supervisor is probably the owner, so your choice is to either live with sexual harassment or find yourself unemployed. And there's evidence showing that the gender wage gap among pharmacists almost completely went away when pharmacies shifted away from mom-and-pops and towards big box stores that hire people to work shifts.

Whenever I hear stories like this, I think of a handful of strips from _Something Positive_ back in 2004:

[http://somethingpositive.net/sp09082004.shtml](http://somethingpositive.net/sp09082004.shtml)

[http://somethingpositive.net/sp09092004.shtml](http://somethingpositive.net/sp09092004.shtml)

[http://somethingpositive.net/sp09102004.shtml](http://somethingpositive.net/sp09102004.shtml)

Small businesses are strictly worse than megacorps, and they're finally getting what's coming to them.

<comment><USER21> > And it's not just about benefits: think also what HR departments can do for > you.

As an employee, your employer's HR department exists for the sole purpose of maximizing the net value that the employer can extract from you, the "human resource" being exploited by the company (and if that maximum turns negative, that can be rephrased as minimizing the net harm you can do to the company.)

If they happen to do something that actually benefits you, that's a side effect, not the main goal.

<comment><USER28> In the phrase "Human Resources", never forget that the first word is an adjective and the second the noun.

</comment></comment></comment><comment><USER29> _> She told me customers come in and browse, find something they like, and compare prices online when she's standing right there. _

This is pretty unethical.

<comment><USER30> What exactly do you think is unethical about it? The store either has the best price or not and it is certainly within the consumers best interest to get the best usage of their money. Is it the fact that "she's standing right there"? Poor behavior doesn't make it unethical. There is no obligation to buy a product just because I am standing in the store.

<comment><USER31> It's unethical to use a store as a showroom and then order the item at a lower price from someone who doesn't have to cover the cost of maintaining said showroom.

Either take the gamble and order online sight-unseen, or pay the higher price involved in maintaining floor space and inventory.

<comment><USER24> So you feel it's unethical to go into a store and compare prices? Disregard the ethics of 2 different sales channels being able to compete on pricing because of different distribution set ups, but in what universe is it the consumers job to make sure "joe from around the block" has a job at this specific store?

Is it impolite to bust out a phone right in front of a sales rep and say "hold on, let me check amazon", sure. But there's no moral responsibility on the customer's part to do business with anyone because "hey man, it's more expensive for me to run this business".

This isn't some surprise to retail. This has been going on for over a decade. You can't compete with the internet on price for (many) things. But you can compete on immediate availability, customer experience, etc. If you're fighting a price fight with the internet, gtfo of retail.

<comment><USER31> _So you feel it 's unethical to go into a store and compare prices?_

As I said, it's unethical to use a store as a showroom and then buy elsewhere. It's a simple concept, and I believe you're being intentionally obtuse and disingenuous in your reply.</comment></comment></comment></comment></comment>


Inevitable IPv6 Migration to Unleash New Opportunities - <AUTHOR> http://www.iafrikan.com/2015/08/21/inevitable-ipv6-migration-to-unleash-new-opportunities/

<comment><USER2>
        $ ping6 www.iafrikan.com
        unknown host</comment>


OS-9: real-time, multi-user, Unix-like OS developed in the 1980s - <AUTHOR> https://en.wikipedia.org/wiki/OS-9 <comment><AUTHOR> "UNIX: An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers."

<comment><USER2> It is a little mean, but funny nontheless. One wonders, though, what they would have had to say on MS-DOS...

</comment></comment><comment><USER3> It was a very nice, if under appreciated OS. A number of robot enthusiasts used it in their robots as it was a much more reliable multitasking 8-bit platform OS than MPM was which was around about the same time.

</comment><comment><USER4> OS-9 was awesome, especially for embedded stuff.

As someone mentioned it ended up on the CoCo III eventually, where it'd run rings around IBM PCs of the day.

</comment><comment><USER5> OS-9 was a great OS.

I ran it on a Coco III with 512k and a hard drive that I got surplus from a DEC guy. I learned C on that system.</comment>


Show HN: Launch-Soon, a Heroku-ready open source LaunchRock-type site - <AUTHOR> https://github.com/JamesChevalier/Launch-Soon

<comment><AUTHOR> I just updated it to use Foundation, so now it's redesigned & fully responsive.</comment>