
“It's The Future” - knowbody
https://circleci.com/blog/its-the-future
======
rajeshp1986
The article perfectly summarizes my frustration and sentiment. These days I
hear these buzzwords all time. I work as a consultant for an enterprise
product and most people whom I meet they somehow catch these buzzwords and
blurt it out in front of everyone during meetings and discussions to either
showoff that they know technology and things that are in the market these
days(also latest iphone, apple news, tesla, space exploration and what not) or
I feel they are somewhat trying to hide their insecurities.

Anyway long story short, most of these people do not really understand why
they need all this rocket science to manage < 500 internal users. One of the
new buzzwords I am hearing these days is mostly related to bigdata and machine
learning. One of my managers came to me and asked me why dont we integrate our
product with hadoop it will solve the performance problems as it can handle
lot of data.

I am frustrated by the industry as a whole. I feel industry is simply
following marketing trends. Imagine the no. of man-hours are put into
investigating technologies and projects dropped mid-way realizing the
technology stack is still immature or not suitable for at all.

~~~
mamcx
This is how we manage this problem at the times when Visual Basic was the king
and we use _instead_ Visual FoxPro.

People want theirs apps to be made with Visual Studio (BTW, FoxPro was part of
the package).

So they ask: "In what is the app made"?

"In Visual, Sir."

Done. End of story (like most of the time, obviously some times people are
more dangerous and press it ;) ).

\----

The point is not focus in the exact _word_ but in what the people _know_ the
word will give to them.

So, for example "Big Data". The meaning for us matter zero. The meaning to
some customer is that it have a largeish excel file that with his current
methods and tools take _too long_ to get results.

So. Do you use "Big Data Tools"?

"Yes Sir."

And what about use Hadoop?

"We use the parts of big data tech necessary for solve this, and if we need to
use hadoop or other _similar tools_ that fit better with your industry and
that use the same principles will depend in our evaluation. Not worry, we know
this"

Or something like that ;). Know that worry the people behind the words have
help me a lot, even with people with WORSE tech skills (damm, I have build
apps for almost iliterate people with big pockets but only witch cellphones as
references of tech!)

And the anecdote about the largeish excel file that was too big and take too
long? Yep, true. And was for one of the largest companies in my country ;)

~~~
artellectual
I think the buzzword abuse exists because of people who don't want to take the
time to learn to real skill, and just want shortcuts to sound smart and
relevant.

I am very skeptical of people who are "BizDev" or "Project Managers" or
"Managers" or "Scrum Master" they generally don't know what they're talking
about and rely on buzzwords.

~~~
pyre
I'm wondering why you have managers in scare quotes. Are you suggestion that
they aren't really managers or that managers as a position is just some sort
of fraud?

Also Project Manager and Scrum Master are just positions that describe roles
and responsibilities an organization / on a team. The people filling those
roles needn't be clueless.

~~~
artellectual
I feel people in those positions are just people who want a job in tech /
startup and have gotten there not because they deserve those positions but
because, they've given up on learning the skills and resorted to becoming a
"manager". At least from my experience this is what I've seen. They generally
don't really add any value because they don't have any skills, don't know how
to do anything.

The positions I mentioned above are usually the position people who failed at
picking up any valuable skill seem to resort to.

------
mrhektor
"-No, look into microservices. It’s the future. It’s how we do everything now.
You take your monolithic app and you split it into like 12 services. One for
each job you do.

That seems excessive"

A 100 times yes. We tried to split our monolithic Rails app into micro-
services built in Go. 2 years and many fires later, we decided to abandon the
project. It was mostly because the monitoring and alerting were now split into
many different pieces. Also, the team spent too much time debating standards
etc. I think micro-services can be valuable, but we definitely didn't do it
right, and I think a lot of companies get it wrong. Any positive experiences
with micro-services here?

~~~
shados
Yeah, we do micro services, the "real" kind. Not the "SOA with a new name
kind", but the "some services are literally a few douzan lines of code and we
have 100x the amount of services as we do devs" kind.

The thing is, you need a massive investment in infrastructure to make it
happen. But once you do, its great. You can create and deploy a new service in
a few seconds. You can rewrite any individual service to be latest and
greatest in an afternoon. Different teams don't have to agree on coding
standards (so you don't argue about it).

But, the infrastructure cost is really high, a big chunk of what you save in
development you pay in devops, and its harder to be "eventually consistant"
(eg: an upgrade of your stack across the board can take 10x longer, because
there's no big push that HAS to happen for a tiny piece to get the benefits).

Monolithic apps have their advantages too, and many forget it: less devops
cost, easier to refactor (especially in statically typed languages: a right
click -> rename will propagate through the entire app) and while its harder to
upgrade the stack, once its done, your entire stack is up to date, not just
parts of it being all over. Code reuse is significantly easier, too.

~~~
mikepurvis
"Different teams don't have to agree on coding standards (so you don't argue
about it)."

Unsure if sarcastic.

~~~
andrewprock
Not at all sarcastic. I've seen endless wheel warring over spaces/tabs, level
of indents. Mostly I ignore it.

------
pbiggar
Author here.

To answer some questions: yes this is obviously poking fun at Docker, but I
also do really believe in Docker. See the follow-up for more on that:
[https://circleci.com/blog/it-really-is-the-
future/](https://circleci.com/blog/it-really-is-the-future/)

In a self-indulgent moment I made a "making of" podcast about this blog post,
which is kinda interesting (more about business than tech):
[http://www.heavybit.com/library/podcasts/to-be-
continuous/ep...](http://www.heavybit.com/library/podcasts/to-be-
continuous/ep-16-its-the-future/)

And if you like this post you'll probably like the rest of the podcast:
[http://www.heavybit.com/library/podcasts/to-be-
continuous/](http://www.heavybit.com/library/podcasts/to-be-continuous/)

~~~
deathanatos
It's a good post. It capture both the innate complexity of the problems some
of us are working on, and the incredible WTF moments involved. Both sides of
your theoretical conversation have their own pitfalls. Everyone in the
comments here seems stuck on the "I don't really need microservices train",
(and there _is_ such a thing as overdoing it … but I've never seen it) but I
can't help but think that Italics nailed it here:

> _-It means they’re shit. Like Mongo._

> I thought Mongo was web scale?

> _-No one else did._

It's so incredibly true, and I laugh (and cry, b/c we use Mongo) at this
section each time I read it. Also, this gets me every time:

> _And he wrote that Katy Perry song?_

------
rjvir
There was a time when Heroku seemed just as foreign to me as Docker does in
this article.

\- So shared webhosting is dead, apparently Heroku is the future?

\- Why Ruby, why not just PHP?

\- Wait, what's Rails? Is that different from Ruby?

\- What's MVC, why do I need that for my simple website?

\- Ok, so I need to install RubyGems? What's a Gemfile.lock? None of these
commands work on Windows.

\- I don't like this new text editor. Why can't I just use Dreamweaver?

\- You keep talking about Git. Do I need that even if I'm working alone?

\- I have to use command line to update my site? Why can't I just use FTP?

\- So Github is separate from Git? And my code is stored on Github, not
Heroku?

\- Wait, I need to install both PGSql and SQLite? Why is this better than
MySQL?

\- Migrations? Huh?

~~~
bertiewhykovich
To be fair, a lot of these questions are valid. You arguably /don't/ need MVC
for yours simple website, if Dreamweaver floats your boat you might as well
use it, it's unclear why a small website needs an elaborate deployment
infrastructure, using a VCS for personal code can be overkill, PGSql and
SQLite aren't better than MySQL for every use case -- and so on.

Frameworks, orchestrations, even just new technologies -- these are great if
they actually make your job easier or if they make your product better.
Unfortunately, they often do exactly the opposite.

~~~
softawre
Agree until

> using a VCS for personal code can be overkill

I've been burned before, have you? If you're using something like Google
Drive, you should use DropBox instead, since it seems less likely to lose your
work.

------
nathell
Obligatory link to "The S stands for simple", a SOAP-bashing classic:
[http://harmful.cat-v.org/software/xml/soap/simple](http://harmful.cat-v.org/software/xml/soap/simple)

~~~
codeulike
Everything must be in XML. Except the SoapAction header. Which has no defined
standard. Yeah I remember all that madness.

~~~
jgalt212
remember? Thomson Reuters on demand APIs are still largely SOAP based.

~~~
fs111
never touch a running system...

~~~
jgalt212
fair enough, but I posit X users started consuming this API when SOAP was
prevalent and Y users started when ReST was prevalent and Y >> X. Furthermore,
SOAP is hard to maintain these days because it's so ancient. i.e. the
libraries are not new and/or actively maintained.

As such, I maintain SOAP should be gone for the good of the running system.

~~~
creshal
In Python you simply don't have good SOAP libraries. They were all started at
the tail end of its popularity and then all died quiet deaths when attention
shifted to ReST before they were actually production ready, and if you now
want to talk to a SOAP service… well, better don't do it in Python. 2, that
is. Forget about 3.

~~~
corford
Have you seen Zeep?

It's literally billed as "A fast and modern Python SOAP client". Python 2 and
3 compatible. Last commit was two weeks ago.

[http://docs.python-zeep.org/en/master/](http://docs.python-
zeep.org/en/master/)

~~~
creshal
Nope. We needed one last September, zeep didn't yet exist back then.

And going by the bugtracker, it's running into quite a few problems with
almost-but-not-quite compliant servers/WSDL files, which is a real issue when
you're trying to interface ass-old legacy APIs (we're talking "not upgraded
since 2006"-old) made by $BigEnterprise. Maybe _this_ time the project won't
die before they work out all the little kinks.

------
chukye
Man, I dont think this is the future at all. OK, Docker is good and has its
propose, and is very good on what its do: "Run only one process in one brand
new kernel", but beyond than that, its just a daemon that uses and abuses of
linux containers, you can easily scale, but is a pain in the ass to upgrade
apps, also you _need_ to run only _one_ process on that. Does not looks like
the future for me to have 30 different linux containers running just only one
process in each of them, dude, you have a kernel in your hand, why the hell
you will run only one process on it? (what the heck, you can protect yourself
and scale without be the bitch of a daemon, you just need to know your best
friend kernel), you dont need to make micro services for everything, its good
ok, but its not the solution for everything like the people are saying...

I really dont have any idea why the people are are so excited about "docker"
all the things.

~~~
piva00
It's all about simplifying deployment. That's it, that's what's so good about
using containers.

I don't know if you understand what Docker really is when you say something
like this: "Run only one process in one brand new kernel", the kernel is
shared between containers, that's the whole idea, you package the things your
application need and be done with it.

The current problem with containerization is that there are no really good or
understood best practices, people are still experimenting and that's why it's
a big moving target and, consequently, a pain in the ass if you need to
support a more enterprise-y environment. You will need to be able to change
and re-architecture things if the state-of-the-art changes tomorrow.

I agree with your sentiment about going overboard on "docker all the things",
that's dumb and some people do it more because of the hype than by
understanding their needs and using a good solution for it but I think you are
criticising something you don't really grasp, these two statements:

 _> "Run only one process in one brand new kernel"_

 _> you have a kernel in your hand, why the hell you will run only one process
on it?_

I'm not trying to be snarky, I really recommend you doing a bit more of
research on Docker to understand how it works. Also, Docker doesn't make it a
pain in the ass to upgrade apps, quite the contrary if you do it in some
proper ways.

~~~
IshKebab
Doesn't statically compiling programs solve the deployment issue better? I
mean, as far as I can tell Docker only exists because it's impossible to link
to glibc statically, so it's virtually impossible to make Linux binaries that
are even vaguely portable.

Except now Go and Rust make it very easy to compile static Linux binaries that
don't depend on glibc, and even cross-compile them easily.

Hell I think it's actually not even _that_ hard to do with C/C++:
[https://www.musl-libc.org/how.html](https://www.musl-libc.org/how.html)

If I have a binary built by Go, what problems does Docker solve that just
copying that binary to a normal machine doesn't?

~~~
jalfresi
Have to admit, as a fellow Go dev, with single binary static compiles, I don't
really GET why I need docker... all it seems to offer is an increased workload
and complicated build proc

~~~
invaliduser
In my humble case, Docker solves the problems I have to manage the systems on
which my application runs (and that's mainly it). A single dockerfile of 20-30
lines describes a whole system (operating system, versions, packages,
libraries, etc), and cherry on the cake, I can version it in my git
repository.

This is not revolutionary in itself, but having the creation and deployment of
a server being 100% replicable (+ fast and easy!) on dev, preproduction, and
production environments, plus it's managed with my usual versionning tool,
that is something I appreciate very much.

Sure, there are other tools to do the same, but docker does the job just fine.

~~~
jacques_chester
> _having the creation and deployment of a server being 100% replicable_

The problem of ensuring that upstream dependencies can be reproducibly
installed and/or built is, of course, left as an exercise for the reader.

------
epalmer
I am going to ramble. Just move on if you don't care to hear the ramblings of
a 62 year old development manager.

I'm pretty docker ignorant. I think I get it in concept. I manage >150 web
sites (~15,000 pages total) that are php based with eXist-db and oracle
(overkill but forced to use it) for database backends. My team develops on mac
os x and pushes code to RHEL. We have never had a compatability problem
between os x and RHEL except for some mgmt scripts in bash that were easily
coded around.

Big data to me is a 400 MB apache log file.

I go home grateful I don't have to be in the buzz word mix.

I do read a lot about technology and over time that informs some changes like
using apache camel for middleware, splunk for log file analysis yada dada...

I have had bosses that brought me buzz word solutions that don't ever match
the problems we have. I hate that but right now I am not in that position. My
boss leaves technology decisions to us.

Least you think we are not modern at all we do use a CDN, git and more.

Some days I get anxiety from reading HN, feeling stupid. Some days I get a
lift from HN from reading articles like this one and the comments.

I am so glad I'm not in the business of chasing technology.

------
hoechst
Please also read the followup ([https://circleci.com/blog/it-really-is-the-
future/](https://circleci.com/blog/it-really-is-the-future/)).

I read both articles a year ago and it really helped me grasp the whole
container movement.

------
robteix
"Why don’t I just use Google’s thing?

"-You think that’s going to be around in 6 months?"

Isn't reputation a thing of beauty?

~~~
droidist2
So true. Why people often use "it's backed by Google" as an argument in favor
of anything is beyond me.

~~~
driusan
"it's backed by Google" is the reason I avoided Go for years and is still the
only reason I'm nervous using it.

~~~
prodigal_erik
If it's free software it won't just disappear. If it's proprietary and hosted
by an org that isn't making real money from it, that's a different story....

~~~
flukus
Is the development open though (serious question, I don't know how they do it
with go)?

Look at android, it's a closed project that the occasionally release some
source code for. If google decided to drop android then it's a critical blow
because there isn't much of a community around it.

~~~
driusan
It depends what you mean by "open." Anyone can subscribe to the go-codereview
mailing list. Anyone can submit a patch, but you need to a) use gerrit and b)
sign a (digital) contribitors license agreement with Google.

It's "open", but it would almost certainly collapse entirely if Google decided
to drop support for it. (There's no sign that they'll do that, but it's not a
risk you take with a language like C.)

~~~
emn13
Even by the most lax standard you couldn't call the app store open; and _that
's_ kind of what's being shuttered here. The technology wasn't ever
particularly interesting (not a bad thing), but the distribution model was.
And that's entirely closed - they're not about to give anyone else permission
to run even parts of the app store to anyone else, and that's that.

------
TickleSteve
Sometimes it seems the webdev world is unaware of the complexity its creating
simply to execute instructions....

~~~
kalleboo
What do you mean? I'm just running bytecode on a virtual machine ontop of a
virtualized container on top of virtualized hardware on a CPU where the
instruction set is virtualized in microcode...

~~~
saynsedit
Reasonable.

------
lambdacomplete
There are 2 major issues with this:

1) Small teams (~1-5 people) trying to seem "big" by working at Google's
scale.

2) Heroku's prices. We are currently (successfully so far) migrating a small
Django project from bare Amazon EC2 instances to ECS with Docker. Even using 3
EC2 micro instances (1 vCPU, 1 GB RAM) for the Docker cluster we would spend
~8 USD/month/instance. With Heroku the minimum would be 25 USD/month/dyno.
That's a 3x increase in expenses.

It's very possible to take advantage of technologies like containers without
getting too caught in the hype.

~~~
baq
wait. you're comparing $25 with $75. it is 3x but it's still accounting noise
by any standard imaginable unless you're running a charity server for an open
source project.

~~~
lmm
What about the standard of "I'm young and this is a side project I'm doing in
a couple of hours at the weekends"? Of course once you have a real company
with more than two customers $75 is nothing. But version 0.1 is often a tool
that's only useful to you.

~~~
jalada
Heroku has free dynos for side projects, and hobby dynos ($7/dyno/month) for
slightly-less-side projects. So that original $75/m quote isn't quite right
for that situation.

~~~
lambdacomplete
Yes it is, our EC2 instances have 1 GB of ram, the 7$ dyno has 512 MB.

------
LukeB_UK
Previous discussion from 434 days ago:
[https://news.ycombinator.com/item?id=9688383](https://news.ycombinator.com/item?id=9688383)

------
xchaotic
I think I will be fine, thanks. I'll stick to my shell scripts, so far they've
outlived any other devops fad.

~~~
tormeh
Why not use Python instead? Shellscript is so... chaotic.

~~~
mbrock
How do you write "foo | bar" in Python?

~~~
IshKebab
How often do you _actually_ need to do that. 99% of `foo | bar` command could
easily be `foo > a && bar < a` which is pretty trivial to do in Python.

~~~
mbrock
Well, how do you write that in Python?

I'm curious because these simple things that are delightfully easy in bash
often turn out to be surprisingly tedious in other languages.

Of course, some things are tedious in bash too. But a basic principle of shell
scripting is that you call other programs to do the stuff you don't want to do
in shell.

~~~
IshKebab
Like this:
[http://stackoverflow.com/a/1996540](http://stackoverflow.com/a/1996540)

I agree it is tedious, but to be honest, reading and writing to stdin/out
isn't something that would commonly need to be done in a robust system. If the
world were perfect you would use library functions.

I definitely think there is scope for a language that works well as an
interactive shell, _and_ as a general purpose language. They have somewhat
conflicting constraints but I'm sure we can do better than Bash. Have you seen
how [ is implemented?

~~~
mbrock
No stdout or stdin for robust systems? I disagree.

Yeah, a nicer shell-like language would be cool. I've been thinking about it
for a while.

Bash is quirky but it gets a lot of stuff right and once you understand it it
can be extremely ergonomic and productive.

And not depending on language run times other than shell can be really
glorious in some situations, too...

------
nickjj
Or just put your app(s) into containers and run them through docker compose on
a single VPS. That bypasses about 99% of the things listed in this article.

You can still easily set things up so it's a git based deploy which is hands
free after the initial push.

Now you have a single $5-10/month server that runs your app's stack without a
big fuss. Of course it's not "web scale" with massive resiliency but when
you're just starting out, 1 server instance is totally fine and exactly what
you want.

I've ran many projects for years on 1 server that did "business mission
critical" tasks like accepting payments, etc..

------
mangeletti
I wonder if the original HN "Heroku is Dead..." title will cost Heroku money /
market share in indirect ways.

When I see titles like that (despite the fact that it was intended as
sarcasm), I think to myself, e.g., "I bet at least hundreds of people who
scrolled past it thought it was sincere, and now they will have this
subconscious 'Heroku is Dead... Docker...' thought at times when deploying
projects. Maybe they'll even check out Docker. Maybe these hundreds of people
will represent a tipping point of sorts for Heroku->Docker migrations, because
one of them will write a really great blog post about it, and it will receive
thousands of views..." (alternate endings of the same thought continue to be
brute-forced for a few moments).

Along the same vein of thinking, back in 2008 I had this "realization" that
Google could control the world by simply showing results based on headline
titles (e.g., a search for "Obama" during the election could have resulted in
articles / results whose titles have words/phrases whose presences are
positively correlated to lower or higher stress levels, assumptions, other
emotions, etc., resulting in a net positive or negative sentiment,
respectively, about the subject of the search query, all while simply scanning
the results to determine which one to click).

~~~
Fiahil
> I wonder if the original HN "Heroku is Dead..." title will cost Heroku money
> / market share in indirect ways.

This would be true for an average BuzzFeed-consuming-crowd, which -to my
knowledge- isn't the case here.

------
oneplane
This pretty much sums it up. New stuff, stacked on existing stuff, with the
theory that older stuff was hard, and new stuff is better, but you still needs
the old stuff, so you basically end up doing exactly what you did, but now
with more stuff in between, adding cost, complexity and additional failure
modes while solving nothing.

Any of the proposed problems that containerization was supposed to fix are
already fixed by using proper configuration management. In almost all cases so
far, people yammering on about docker and containers (and CoreOS), it ended up
being their idea of configuration management, because they didn't have any in
the first place.

Say you want to fix your 'problems' with setting up servers, how about doing
it the right way. You will need deployment services, regardless of containers,
VMs or bare metal. You will also need configuration management services, and
monitoring. Containers and special distributions solve none of it, knowledge
to run systems is still required and not actually fixing your problems and
layering stuff on top of it doesn't actually help.

Get something like SaltStack or Chef, and configure the ____out of everything.
It doesn 't care what you're running on, and actually solves the problems that
need fixing.

------
nathan_f77
I've spun up a lot of kubernetes clusters to test it out. A few months ago I
also tested out Flynn, Deis, Deis Workflow, Openstack, and a lot of other
options. I still haven't found a simple bootstrap script that gets everything
set up on AWS and lets me simply deploy my application. And it's true that
storage still seems to be an unsolved problem with kubernetes.

Heroku is great, and free for small services. On the other hand, a highly-
available kubernetes cluster is going to set you back at least $100 per month,
which is just too much for small startups and side projects before they take
off.

I think I'm going to forget everything and head towards
[http://serverless.com/](http://serverless.com/). No Heroku, no Docker, no
micro-services, no servers. Just everything running on AWS Lambda and
DynamoDB. And everything static in S3 behind Cloudfront.

Or maybe just Firebase. But I really am tired of managing servers.

~~~
numbsafari
So, why not ditch AWS and use GCP? Kubernetes cluster setup in one command, or
use AppEngine.

Maybe the problem is AWS.

~~~
zeveb
> So, why not ditch AWS and use GCP?

It's a Google product offering, which means it could be EOLed tomorrow. Or
this afternoon. Or maybe it already has — better go check their blog.

~~~
numbsafari
Amazon and Google have almost the exact same language in their ToS for
deprecation policies. Also, k8s is open source, so you can at least go
somewhere else if you really must.

GCP isn't "Google Labs".

------
jakozaur
Thumb rule: Divide number of backend engineers by 5 you get optimal number of
micro-services.

~~~
degenerate
I got 0.2

Should I round up or down?

~~~
krallja
Congratulations! It's serverless!

------
lopatin
I got a genuine laugh out of this quote "Yeah, BDSM. It’s San Francisco.
Everyone’s into distributed systems and BDSM.".

~~~
bbctol
Thought it was a joke, then quickly googled Aphyr's blog...

------
eddd
Making sort of funny articles about Docker doesn't change the fact that
circleci's support for docker is horrible. I don't use it on prod (and I
probably won't) but since circleci forces me to use ubuntu 12.04 which is not
something I use on prod I want a docker container which looks like my
production host. Having said that - circle really tries to support docker, but
It doesn't.

I have to use ECS for caching (I am not happy about it)

Builds might fail due to the custom docker version/compilation

You can mock docker, but people are using it in one way or another and you
should support it properly.

------
seanhandley
This needs a "(2015)" adding to the title.

~~~
CrLf
Because 2015 was, like, 100 years ago...

~~~
imtringued
Containers are obsolete. AWS Lamba is the new hot thing.

------
room271
Most commenters don't seem to realise that this is satirical, and that the
author actually thinks Docker is 'the future':

[https://circleci.com/blog/it-really-is-the-
future/](https://circleci.com/blog/it-really-is-the-future/)

But there is, as the author notes, truth in the satire.

------
hellofunk
I assume this entire article is one piece of sarcasm. Because after reading
it, how could any sane person not prefer Heroku?

~~~
paride5745
From your comment I see you didn't read the post.

Read it, it's a lovely 5 minutes piece of writing.

~~~
hellofunk
It looks like I was not the only one to be confused:
[https://circleci.com/blog/it-really-is-the-
future/](https://circleci.com/blog/it-really-is-the-future/)

------
sandGorgon
show me an easy way to push a rails application to aws (with docker) that uses
RDS ?

is there ANY way i can spin up a server, add the ssh keys to some
configuration file somewhere and just "docker-magic push" and have my rails
application running ?

or do "docker-magic bundle exec db:migrate" and have that command run on the
server.

Or push a Procfile with worker definitions and have the PAAS automatically
pick it up, add it to supervisord/systemd and run it ?

~~~
nickjj
Once you finish taking my Scaling Docker on AWS course, you'll have access to
a magic command that deploys your app and you're free to optionally run
migrations.

[http://nickjanetakis.com/courses/scaling-docker-on-
aws](http://nickjanetakis.com/courses/scaling-docker-on-aws)

It covers using RDS, ElastiCache and also handles load balancing your app +
much more.

~~~
goldenkey
You should mention it costs $20 for information that can be found for free
anywhere on the web. While other users answer the question, you simply refer
to your piggy bank, shameless.

~~~
nickjj
> You should mention it costs $20 for information that can be found for free
> anywhere on the web. While other users answer the question, you simply refer
> to your piggy bank, shameless.

Yep, it costs $20. Basically the cost of chinese food for 2, to ensure
guaranteed victory in learning the essentials of AWS' platform while having a
guided tour on how to deploy a fault tolerant web app with Amazon ECS from
start to finish.

You can definitely learn everything for free, but the value in a course is
that you're getting a cohesive learning path that was carefully planned and
tested. You get a system that you can apply to your own projects and plenty of
source code to reference.

You're paying the $20 so you can avoid spending 6 months trying to figure out
everything on your own while stringing together a bunch of half-assed blog
posts and tutorials.

You pay the small fee for certainty and it's well worth it because your time
(and sanity) is not infinite.

~~~
goldenkey
I love the comparison to chinese food for 2. As if everyone lives in the US
with the same economic situation. Your posts are truly despicable.

~~~
nickjj
I'm sorry you feel that way. Unfortunately time is something we all share, and
it brings me a lot of joy to have students say that my courses have saved them
a ton of time and helped them meet their goals.

I see that you recently left Amazon after making 200k/year there (a comment
you made 5 days ago). I can see why you don't like people promoting Amazon
products, I fully understand.

~~~
goldenkey
Condescension abounds! :-)

------
cocktailpeanuts
Glad to know there's the same kind of hipsterism going on in the backend world
as much as in the frontend world.

You could basically substitute all these backend buzzwords with "Webpack",
"Grunt", "Gulp", "Requirejs", "React", "Angular", "Ember", "Backbone", etc.
and it would have same effect on the readers--they think you're an annoying
hipster.

------
joeblau
[https://www.gitignore.io](https://www.gitignore.io) runs on Heroku and it
gets 40k+ visitors a month on a free Dyno. I use Heroku because I don't want
an IAAS solution, I want a PAAS solution. If I wasn't using Heroku, I would
probably find another PAAS, before switching to Docker (even though I do love
Docker).

~~~
Svenskunganka
That's 1 request per minute, you could slap that into a raspberry pi on a 3G
connection, and do the same for your next 400 apps that has 1 request per
minute.

People seem to underestimate just how powerful modern machines really are. And
I don't get why people seem to think it's hard to deploy simple web
applications. Just write a 4-line shell script that rsync's, runs whatever DB
migrations you may have and restarts the thing.

~~~
forgottenacc56
40k visitors per month isn't one per minute. It's anywhere from one per minute
to 40k per second. Division of requests by time is the worst possible mistake
in calculating load.

~~~
buro9
Plus visitors != requests.

I have 200k visitors per month generating 8m page views and about 50m hits on
the servers (with CDNs taking another few hundred million hits).

These all peak during the UK weekdays and wind down at nights and weekends.

Divisions over time aren't going to work, but neither is translating visitors
into requests, especially as it's only the page views that have a beyond
trivial computation cost.

~~~
joeblau
Yeah, I just checked Cloudlfare and here are the requests

    
    
      Total Requests
      Last Month
      622,482

------
djhworld
One thing that I liked about Heroku was the ease of deployment for Java
applications (or any language for that matter as long as you had the right
build pack)

Since they upped the cost of their small tier, I moved to Digital Ocean and
installed Dokku, which gives me that Heroku-like deployment experience so
managing my (admittedly very small) website isn't that much of a hassle.

~~~
axelfontaine
We at Boxfuse ([https://boxfuse.com](https://boxfuse.com)) provide the same
ease of deployment for running Java apps (as well as Go and Node.js ones) on
AWS. All you need to type is literally: boxfuse run myapp-1.0.jar -env=prod

And you automatically get things like auto-scaling, database auto-
provisioning. easy debugging and more.

Disclaimer: I'm Boxfuse's founder and CEO

~~~
atoko
Hey, it looks like your "center-iframe" is pointing to an invalid link. It
threw me off while I was looking around. Hope this helps

------
dredmorbius
In an earlier age, all we had to hate were frameworks.

[http://discuss.joelonsoftware.com/?joel.3.219431.12](http://discuss.joelonsoftware.com/?joel.3.219431.12)

(Factory factory factory factory.)

------
nicolas_t
Out of topic but, man, is coreos not ready for prime time. I've been using it
following the stable channel and ended up having to turn off automated updates
because it would break docker (docker would just hang with the last 4
updates)... Not a very convincing test of coreos :)

------
jondubois
Kubernetes/Docker will become increasingly accessible to developers and it
will loosen the reliance on lock-in PaaS like Heroku - This is the future; I'm
betting everything on it.

With tools like Rancher [http://rancher.com](http://rancher.com), you can
already see things moving in that direction. Next step is rancher-as-a-
service.

When it comes to developers, I think open systems will always prevail in the
end (it's just more flexible).

~~~
vpol
I thought it's more important WHAT you run inside containers than containers
itself.

I got really upset about this rancher tool because it doesn't design my
database schema.

Shit, future was so close.

~~~
jondubois
You still have to write code, define your database schema and declare config
files to specify how containers should be orchestrated but soon open source
developers will start creating frameworks/boilerplates which capture some of
these requirements and which can automatically run and scale on
Kubernetes/Swarm/Mesos and this will greatly speed up application development
and deployment.

Right now, we think of frameworks as being components (part of) larger
software systems - But in the future, frameworks will provide the foundations
for entire software systems - They will be be responsible for declaring their
own network topologies and resource requirements and they will be capable of
scaling automatically to any number of machines.

Developers will extend and customize the framework with their own logic but
the framework itself will handle all the difficult stuff related to its own
operations.

~~~
vpol
[sarcasm]

------
qwertyuiop924
Don't listen to hype. Look at the problems you need to solve. If you need a
big, complex, distributed system, than maybe microservices are a good idea. If
you're building a simple webapp... not so much. Things that work in the large
don't necessarily work in the small.

I write stuff in Scheme. I'm a hobbyist, there's no reason for me not to, and
I love the language. The apps I write are sometimes single-threaded (or
coroutine-based) monoliths. But I only have one machine available for me, and
the things I'm writing are fairly simple. It's good ENOUGH. And Worse really
is Better[1].

1:and I truly mean that in the Gabriel sense. As in the New Jersey model. Not
any other way.

~~~
jventura
For people who do not know what "Worse is Better" means, here's the link:
[https://www.jwz.org/doc/worse-is-better.html](https://www.jwz.org/doc/worse-
is-better.html)

~~~
softawre
WTF is at that link? It's NSFW...

------
cerebellum42
This definitely reflects some of my experiences when trying out Docker and
some of the other stuff associated with it.

Serious question though: I would absolutely love to have an introduction on
how to use Docker to deploy one or two web applications that use a typical
amount of backend services, say some sort of database and a redis server. All
of this would probably run on a single VM (whether Amazon, DigitalOcean,
Linode, ...) and you mainly use Docker to isolate the applications from each
other in terms of the environment/dependencies that they need.

How do I do this with Docker in a way that gets me an easy deploy process? (Or
maybe the question is actually, should I even do this with Docker?)

~~~
pbecotte
My personal blog is basically an example of deploying a simple app using
docker. HTTPS://GitHub.com/pbecotte/devblog ... The makefile wraps up the
actual commands.

------
joryhatton
> No, look into microservices. It’s the future. It’s how we do everything now.
> You take your monolithic app and you split it into like 12 services. One for
> each job you do.

 _reader implements and gets massive bill for personal blog hosting_

"Am I doing this right?"

------
tedmiston
I guess this is meant to be hyperbolic but honestly it's true.

> So I just need to split my simple CRUD app into 12 microservices, each with
> their own APIs which call each others’ APIs but handle failure resiliently,
> put them into Docker containers, launch a fleet of 8 machines which are
> Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes
> cluster running etcd, figure out the “open questions” of networking and
> storage, and then I continuously deliver multiple redundant copies of each
> microservice to my fleet. Is that it?

> -Yes! Isn’t it glorious?

> I’m going back to Heroku.

------
StreamBright
What a nice clickbait title. A is better than B, even though A is an apple
while B is an orange, and we use them for entirely different purposes. Some
functionality provided by Heroku can be replaced with Docker, and some missing
features of Heroku are in the Docker infra, that can be added to Heroku using
software (like service discovery:
[https://blog.heroku.com/managing_your_microservices_on_herok...](https://blog.heroku.com/managing_your_microservices_on_heroku_with_netflix_s_eureka))

~~~
BellsOnSunday
It's a humorous lament on the fragmented state of devops, not to be taken too
seriously.

------
linkregister
I actually learned a couple of things from this article even though it's
satire. I struggled through the de-monolithing of an application into
microservices and then into Docker containers. Do people actually do this
without having pressing issues that haven't lead them to this path? Is there
any reason to spread into microservices unless the monolith is not keeping up
with requests?

I would have never considered Docker containers unless artifact
preservation/isolation and deployment issues hadn't forced me to look toward a
solution.

------
golergka
Look, if you're a one man shop doing a small project — do LAMP. Do perl. Do
cgi. Do whatever you're comfortable with; if you try to switch to the latest
silver bullet tech, you'll just get disappointed.

But if you're a CTO with a startup with 10+ server-side developers and plan to
hire at least as much in near future, suddenly all these dockers and
microservices actually make sense.

So, unless you'll start conversations with _who_ you are and _what problem_
are you trying to solve, of course the other side will seem stupid.

~~~
manarth
> _if you 're a CTO with a startup with 10+ server-side developers and plan to
> hire at least as much in near future, suddenly all these dockers and
> microservices actually make sense_

As a consultant, I often get asked those kinds of questions: "Should we use
X?"

Whether it's programming languages, databases, operating systems, whether it's
Chef vs Puppet vs Ansible vs Docker vs Whatever, it's a question that comes up
a lot.

I generally answer it with "What are your team good at? What have they used,
what do they know well?"

There are always exceptions to the rule, but in general I encourage people to
play to the strengths of their team, rather than recommending Technology X
because it's shiny and bang on-trend.

~~~
golergka
Exactly my point. I used two broad categories just to paint the overall
picture; the fact that they "make sense" doesn't mean that they're the silver
bullet.

------
QuantumRoar
I'm not a web developer but I sometimes put some programs on the web for me
and my friends. I use FreeBSD Jails for that.

Can someone explain to me the advantages of Docker compared to Jails?

~~~
chillydawg
In your use case: pretty much no advantages. Stick with jails and be happy.

------
jwmoz
Reminds me of
[https://www.youtube.com/watch?v=b2F-DItXtZs](https://www.youtube.com/watch?v=b2F-DItXtZs)

------
raverbashing
Also

Hitler uses Docker:
[https://www.youtube.com/watch?v=PivpCKEiQOQ](https://www.youtube.com/watch?v=PivpCKEiQOQ)

~~~
ex_amazon_sde
Really spot on - recommended! "You are a bunch of Node.js hipsters that just
HAVE to install everything you read on Hacker News!"

By the way, why all the downvotes to the parent?

------
imtringued
Since we are seeing so many "ads" here in this discussion. Does the average HN
reader prefer this type of advertising to regular adsense ads? There is no
violation of privacy, no autoplaying video, they are actually relevant to the
discussion and it's obvious that they are trying to sell you something. Oh and
probably the most important thing si you can downvote them.

~~~
LukeB_UK
I dislike it because they just seem to have read the title and not the actual
post.

------
h8x0rd
He slowly caressed his docker image while tenderly inserting it in the
continuous delivery pipeline. The slow throbbing of the Jenkins service
increased in intensity as the automated tests started firing off in a
crescendo of etcd writes leaving a quivering micro-service that lay panting in
its pod. That was a memorable deployment. The first of many that night...

------
geggam
See .... microservices are where you take a process using IPC and force it to
go over a network and use TCP ...then you pretend it will run better and scale
more but avoid the whole 10x infrastructure growth and the fact the devops
team has tripled in size to manage the frankenstein ... dont forget to add in
the whole SDN layer the network guys absolutely love

------
forgottenacc56
I'm not sure I get the message.

~~~
pawelkomarnicki
heroku is dead, docker is awesome, gluten free food does not have gluten ;-)

~~~
forgottenacc56
I'm sure I don't get that message.

~~~
Pyxl101
It's all sarcastic. It's poking fun at how trendy advances might not
necessarily be better than what existed before, as well as how much complexity
is involved in them. It makes the most sense if you're already familiar with
the concepts in the article (Docker, Heroku, CoreOS, etcd, and so on), and
happenings in the technology industry related to them.

As usual, if a joke needs to be explained (to a person) then it's not funny
(to them). I found this amusing since it aligned with my experiences:

> -Since no-one understands Paxos, this guy Diego…

> Oh, you know him?

> -No, he works at CoreOS. Anyway, Diego built Raft for his PhD thesis cause
> Paxos was too hard. Wicked smart dude. And then he wrote etcd as an
> implementation, and Aphyr said it wasn’t shit.

> What’s Aphyr?

> -Aphyr is that guy who wrote, ‘Call Me Maybe.’ You know, the distributed
> systems and BDSM guy?

> What? Did you say BDSM?

There are several jokes here based on cultural references related to the
aforementioned topics.

~~~
reitanqild
I learned that <x> will laugh at a joke three times:

* First when you tell it,

* then when you explain it,

* then finally when they get it.

(x used to be English people when I was a kid.)

~~~
DonHopkins
A gentle reminder that it's against the Hacker News guidelines to leave
unclosed xml tags in your comments.

~~~
rb12345
Surely that's BNF rather than XML?

------
discordianfish
Hype is as bad as seeing a promising technology just as hype without trying
understand the problems it might solve.

This is quite frustrating for both people who are aware of those issues and
trying to fix them as well as the people missing out on the real advantages of
such technologies.

This reminds me of similar sentiment around virtualization and cloud computing
later in my peer group:

Some sold VMs as security feature and people focused their criticism on that,
without understanding other advantages like quick/self-service provisioning of
systems. Later one, cloud computing was trivialized as "it now just somebody
elses computer" which completely ignored advantages like no ramp up costs and
the ability to problematically manage your systems life cycle.

PS: Considering every new thing a fad probably also makes you consider
'hadoop' the latest shit in big data processing and assume today's tech
companies hipster are fighting over wordpress plugins. (Like, really?)

------
beweinreich
As someone who recently drove down the path of learning all the new "hotness"
in the DevOps world, I can safely say I came out of it with two learnings:

1\. I have a much better understanding of what's happening behind-the-scenes

2\. For most small startups, you should seriously consider the time (and
therefore, cost) of investing in your own infrastructure.

For point #1, I think understanding your options and how they benefit your
company is essential for you transition from a small -> medium -> large size
company. The paradigms you learn by virtue of researching the new technologies
might end up being applicable in other parts of your development process.

On point #2, I partially regret not deploying to Heroku, seeing where our
system became stressed, and optimizing. Attempting to scale for things you
don't know about yet is tough, and can lead you down a path of wasted time and
money.

------
farorm
Well I think that people and developers in particular needs to start realising
that companies like docker has gotten really good at marketing them selfs
towards them. Most of the stuff you hear about a technology is just marketing
stuff that makes you sound smart when telling your peer about a new
technology.

------
jfoutz
> So I just need to split my simple CRUD app into 12 microservices, each with
> their own APIs which call each others’ APIs but handle failure resiliently,
> put them into Docker containers, launch a fleet of 8 machines which are
> Docker hosts running CoreOS, “orchestrate” them using a small Kubernetes
> cluster running etcd, figure out the “open questions” of networking and
> storage, and then I continuously deliver multiple redundant copies of each
> microservice to my fleet. Is that it?

 _exactly. I mean look, if you have a lifestyle business that 's only going to
support 5-10 people, it's totally a waste of time. if you have some hope of
scaling this is the way to go. I get it, just use Heroku. It's easy and
convenient. If you're planning on a billion dollar exit, this way is way
better._

> I need to decide if i believe my own hype?

 _yeah. sorry._

------
EGreg
You know what's better than microservices? Nodes. Nodes running open source
software that can power a distributed network.

Microservices often hit the same database. You want to be able to split up the
database. Not just into shards, but into distributed nodes.

And by doing this, you split up the whole stack.

------
laithshadeed
I believe microservice is the wrong term used to describe SOA. The word
'micro' make it looks simple & applicable for tiny apps 10-50K SLOC. I believe
you should start chopping off your monolithic app only when it reach > 100K
SLOC. Still you can split it up by well defined modules with clear interface,
without necessarily using SOA if it is running on same box.

Having monolithic app does not make it bad. What makes it bad is not having
proper modules with proper interfaces.

SOA comes handy when you want to distribute your workload, so now we have
proper modules but those modules needs more computing power, so split them up
into boxes and pay the pain for managing that, because you have no option.

------
brightball
As the author of that "Docker is the Heroku Killer" post that was popular a
couple of years ago I have to say that I agree with this.

When I wrote that article it was largely focused on the potential for Docker
to create a bunch of Heroku competitors as well as a simplified development
experience across multiple languages.

The businesses aren't there yet although a ton are trying. The local dev
experience has not materialized yet either outside of native Linux due to
performance issues with volumes that only a 3rd party rsync plugin have come
close to fixing.

I still use and advocate for Heroku pretty heavily for just about any non-
enterprise environment.

~~~
BenfromOz
I'm working on one of those Docker powered Heroku "competitors". This post and
your post both rung true for me.

It's a constant balancing act. Too flexible, it becomes overwhelming. Too
constrained and you sacrifice a bunch of the perks of using Docker.

The conclusion I've come to is the only way to do it is to be unashamedly
opinionated about keeping things simple for the average user. Otherwise you
end up having that exact conversation

~~~
brightball
Yea. The most realistic way to get things working IMO is Dockerfiles with 80%
use case defaults for parts of the stack. From there if people want/need to
dive in and tweak them they'd have the ability to do so but ideally the
average user doesn't need to know they are touching Docker much beyond knowing
that it's there if they need it.

------
jpalomaki
When it comes to micro services and containers, we are are missing fairly
detailed descriptions of real world architectures from successful projects.
And actually that applies to many other technologies as well.

When it comes to micro service, it would be interesting to know simple things
like what kind of services were created, how large are, how communiction is
handled, how large team(s) behind the service etc.

For some companies these are of course trade secrets, but sometimes opening
things up might be good marketing. An example is Backblaze with their very
detailed descriptions of their storage pods.

~~~
mooreds
Would you find this presentation useful?

[https://www.infoq.com/presentations/microservices-
comparison...](https://www.infoq.com/presentations/microservices-comparison-
evolution)

------
mtrycz
Is there a computer-voice teddy-bear version of this?

I find them much better than walls of text.

------
spriggan3
Clickbait titles like that don't make me want to do business with circleci ,
it feels like a business full of immature kids yelling at each others. Not
even going to click on the link.

------
atulatul
Not exact but somewhat similar feelings expressed here: Let Me Just Code:
[http://www.drdobbs.com/tools/just-let-me-
code/240168735](http://www.drdobbs.com/tools/just-let-me-code/240168735)

Getting Back To Coding [http://www.drdobbs.com/architecture-and-
design/getting-back-...](http://www.drdobbs.com/architecture-and-
design/getting-back-to-coding/240168771)

------
nickbauman
What containers do for you is two and only two coarse-grained things. 1. Make
you more productive rolling out validated infra 2. Better utilize your
hardware. Both of these things imply that you were using VM/AMIs before and
you were hand-crafting your entire stack using things like Chef and Ansible.
If you weren't doing that before (like, if you were using Google App Engine or
Elastic Beanstalk or Lambda), Docker will make you _less_ productive than you
are today.

------
Almaviva
I think words are very powerful, in particular "microservices" vs "monolith".
By accepting those words, we imply the conclusion: microservices sound sexy
and lean and elegant - who can argue with separation of concerns? And a
monolith is a big unchangeable rock.

I think we need a better word for apps that are single tight self-contained
systems than "monolith". You can design elegant interfaces, and avoid creating
a sloppy mess, with function calls or objects too.

------
josh_carterPDX
It's amazing that an article from a year ago can still create a buzz on HN
like this. Goes to show there are still a lot of people talking about this.

------
DonHopkins
Where do Beowulf Clusters fit into all of this?

~~~
radarsat1
I'm actually looking into using Docker as an easier way to deploy my software
to a Beowulf cluster..

------
oelmekki
"Hi, my name is dokku, and I have no idea what you're talking about" :)

This rant sounds just like any rant from old dev mocking a new tech. "This is
less efficient, this is too complicated, this can't be taken seriously, this
won't last".

Creating a character obsessed with "this is dead" hardly dissimulate the
obsession with "this won't work". Do whatever you please, we don't care. But
don't mock others about what they please.

Passing through that, let's address the critics.

Microservices and docker are not necessarily tied. I write only monolithic
apps, and use them with docker through dokku.

Etcd is a microservice problem, not a docker one.

You don't need coreos or kubernetes to use docker in production. You need them
if you want massively scaled applications, just like you would have many
servers running the same app with replication without docker. Most of us don't
need that (and those who need it probably won't find it more complicated than
what is needed to do that without docker).

If you don't want to manage servers, well, don't manage them. That's what
cloud services are made for. But please tolerate some people love devops and
not spending much direct money into infrastructure.

~~~
collyw
>This rant sounds just like any rant from old dev mocking a new tech.

Probably because we have seen it all before, and there isn't much "new" most
of the time.

~~~
oelmekki
I've been a professional developer for ten years myself, I've seen my part of
hype. But I've seen way more people not even trying new things (and trying
does not mean sticking with it on your main project), probably because they
could not stand the idea that the experience they are so proud of could be
invalidated in any way.

------
wyldfire
I must've missed a tech cycle (or two) - I had heard of Heroku but didn't know
what it did. I've used lxc and Docker and read bits about
CoreOS/rkt/appc/kubernetes/etcd.

I know it's tongue-in-cheek but few if any of these new fangled things are
critically dependent on one another.

------
colemannerd
This comment is over simplistic and reads like it was written by someone who
doesn't know what they're talking about. All of these technologies have their
place, but they should be adopted incrementally and where it makes sense.
Posting a frenetic conversation benefits no one.

~~~
Florin_Andrei
[https://en.wiktionary.org/wiki/joke](https://en.wiktionary.org/wiki/joke)

------
a-priori
There's a theory in economics about the optimal size of a firm. How big should
a company be? The optimal size could be infinite, where all of society acts as
one firm. Think Communist-style command economy. Or it could be one, where
everyone acts as networks of individual contractors or single-owner
businesses. Think anarcho-capitalism. But in reality it's neither extreme and
falls somewhere in the middle; why?

It turns out that the optimal size depends on the balance between the overhead
costs associated with allocating resources within one firm and the transaction
costs associated with two firms doing business with each other. The overhead
costs are higher with large firms because there's more internal resources,
including people, to allocate. On the other hand, transaction costs are higher
with small firms because each firm does less themselves so they need to
transact more with others to accomplish their goals.

As the relative costs vary over time, the optimal size varies too, and firms
in an industry will grow and shrink. If it increases, then you'll see mergers
and acquisitions produce larger firms. If it decreases then you'll see firms
start splitting or small startups disrupting their lumbering competition.

I suspect a similar thing happens in software, where there's an optimal
service size. It could be infinite, where it makes sense to build large
monoliths to reduce the cost of two systems communicating. Or it could be one,
where it's optimal to break the system at as fine a granularity as possible
(function level?).

The optimal size depends on the balance of costs. All else being equal, by
drawing a service boundary between two bits of functionality you shrink the
services on either side but you increase the number of services and add
communication costs for them to exchange data and commands.

How these costs balance out depends on the technology, and there are competing
forces at work. As languages, libraries and frameworks improve, we can manage
larger systems at lower costs. That tends to increase the optimal service
size. As platforms, protocols and infrastructure tools improve, the costs to
run large numbers of services decreases. That tends to decrease the optimal
service size.

The microservices movement, and to an extent the serverless movement, assume
that in the medium- and long-term the technological improvements are going to
tip the scales sharply in favour of small services. I agree that's likely the
case. But we're not there yet, except in some specialized cases such as large
distributed organizations (Conway's law). But it's going to be at least a few
years before it's worthwhile to build most software systems in a microservice
architecture.

------
thearn4
This is structured like one of those Xtranormal do-it-yourself cartoons from a
few years back.

------
partycoder
Well, repeating buzzwords and pushing for early technology adoption for the
sake of early technology adoption seems to be dumb, as the article implies.

But new technology is necessary and early adopters are necessary. Iteration is
necessary. Don't punish it.

------
wjd2030
I love everything about this.

------
reledi
The post got one critical detail wrong. The microservices won't have their own
API. APIs are dead. They'll use Kafka for messaging. That's the future.

------
cdnsteve
Duplicate story:
[https://news.ycombinator.com/item?id=9688383](https://news.ycombinator.com/item?id=9688383)

------
samhunta
This reminds me of React state. Sagas, selectors, constants, components,
containers, routes, reducers, actions, connectors, shoot me.

------
daveheq
Check back next year for Docker is dead article.

------
vpol
Yet another comparison of hot and soft.

~~~
vpol
sounds like "POSTGRESQL IS DEAD, USE KUBERNETES INSTEAD"

------
krisgenre
Is there really something called "Ew" ? Its hard to Google something thats
just two chars.

~~~
pbiggar
The search term is "Jimmy Fallon ew".

------
jgalt212
Question:

Is there an advantage to using docker when it takes 3 hours to rebuild our
relatively small database?

~~~
bbcbasic
Did you read it?

~~~
jgalt212
Sorry, I was lazy. I did not read it.

------
rendambathu
this old gem is back trending now!

------
rjcrystal
doesn't anyone think about performance anymore? I mean just add more vms or
increase their config, no one talks about efficient resource utilization
asfaik. And there might be times where you containerizing everything is an
over overkill.

~~~
pbiggar
Funnily enough, people do. In fact, containerization came from Google caring a
lot about performance! A good intro to how containers help, and to the
probable future of computation:
[http://m.youtube.com/watch?v=7MwxA4Fj2l4](http://m.youtube.com/watch?v=7MwxA4Fj2l4)

------
snambi
Really Hilarious and Reality. Lot of noise about docker, kubernates,
microservices etc.

------
saynsedit
Wow, what a strawman. Seems like someone was blowing off some steam.

~~~
toolz
Depends on how you choose to read it. I love microservices and all the new
tools we have to scale gracefully, but I read this as satire. It's more
hyperbole on how some people always seem to be over-engineering and pretending
that's the conservative way to write software without considering the time-
sink required to be able to dynamically scale with all of those tools.

~~~
saynsedit
Calling this satire insults the skill and wit of competent satirists the world
over.

It's not clever or funny. It's lazy. It's exaggerated to the point of
questionable emotional stability on the part of the writer.

Actually it is funny, but only in an ironic way.

"-Well, Amazon has ECS, but you gotta write XML or some shit."

------
SurrealSoul
"I thought Mongo was web scale?"

This joke will never get old to me

------
audessuscest
Is it a blank page ? I don't see any text.

~~~
dredmorbius
No, it's not.

Even renders on console browsers.

~~~
forgottenacc56
Did you read this on an Xbox?

------
mrich
Lovin' it!

------
_pmf_
Did you just tell me to go containerize myself?

------
trevyn
(2015)

------
marknadal
Self admittedly, I am one of the P2P psychotic pundits. This is a good
reminder that we need to tone our language down.

That said, if you can get your system to work with a single Heroku box, you
really truly can simplify your life. That is what we're trying to do with
[http://gun.js.org/](http://gun.js.org/) , be able to start with a single
machine and no configuration/setup/complexity. Then grow out.

We just had a discussion on the WebPlatform Podcast about all of this P2P
stuff
([https://www.youtube.com/watch?v=NYiArgkAklE](https://www.youtube.com/watch?v=NYiArgkAklE))
although, like I said, I probably got too jargony.

But props to circleci for calling out the elephant in the room. Great
marketing actually.

------
clifanatic
I'm sure I could go back 5 years and see an almost identical complaint about
Heroku.

------
bbcbasic
Solution: .NET

------
jondubois
That's why we started [https://baasil.io/](https://baasil.io/).

The idea is you can deploy any app to any infrastructure of your choice
(inside Docker containers). This means that you are not locked into Heroku and
it gives you much more flexibility.

It's basically a hosted Rancher [http://rancher.com/](http://rancher.com/)
service with a focus on a specific stack.

I think in the future, there will be a lot of services like Baasil.io
(specializing in various stacks/frameworks) and managed by various open source
communities.

Docker and Kubernetes WILL become more accessible to developers - I would bet
my life on it.

I'm currently building a CLI tool to allow deploying in a single command - So
you can get the simplicity of Heroku while not losing any flexibility/control
over your architecture.

~~~
nbevans
But all you've done is shift the problem to, er, you. If someone is
uncomfortable taking out a dependency on say Azure or AWS - the two leading
Docker hosting platforms, then they sure as hell aren't going to take out a
dependency on "baasil.io" are they?

~~~
jondubois
Um no, Rancher is open source can run and manage ANY infrastructure (including
Amazon EC2) - You can run it on your own datacenter or even on your own local
machine.

Also Baasil.io is essentially just a control panel/dashboard (Rancher-as-a-
service), you can quit Baasil.io at any time and switch to your own hosted
Rancher instance and you don't have to change any of your application code or
change infrastructure providers.

The main benefit of Baasil.io is that it was built by an open source community
using open source software and so we can offer the best possible support for
apps built on top of our own open source stacks.

~~~
nbevans
I took one look at "baasil.io" and saw the typical landing page with a "Plans"
link at the top and questioned why anyone would want to take a dependency on
this. If there is some OSS project behind the plan-based charade then that's
fine.

"Also Baasil.io is essentially just a control panel/dashboard (Rancher-as-a-
service), you can quit Baasil.io at any time and switch to your own hosted
Rancher instance and you don't have to change any of your application code or
change infrastructure providers."

But so you can with AWS and Azure - especially with their Docker offerings. So
I'm not sure what problem baasil.io actually solves? If anything it just adds
to the list of dependencies and points of failure.

~~~
jondubois
The main benefit of Baasil.io is that it offers developers a
boilerplate/framework which they can extend with their own code (to build
scalable realtime apps and services) - Any app/service built on top of this
boilerplate can be automatically scaled to 1000 hosts/nodes using a single
command.

Users don't have to use Baasil.io, but if they do, they will get the best
possible support - For example, a customer can give us access to their Rancher
control panel and this would allow us to SSH into their machines to help
resolve any problems in a hands-on way.

It's probably more accurate to describe it as "DevOps as a service - With a
focus on realtime apps/services". The value proposition is probably closest to
Cloud 66 [http://www.cloud66.com/](http://www.cloud66.com/) except more
focused on realtime apps.

Another similar service is Zeit.co [https://zeit.co/](https://zeit.co/) \-
Except Zeit.co only runs Node.js. Baasil.io can be extended with components
written in any language.

