
Getting started with microservices and kubernetes - techterrier
https://medium.com/p/getting-started-with-microservices-and-kubernetes-76354312b556
======
mark242
Two pieces of feedback.

First, tutorials like this should include getting this running using TLS by
default. Ideally there shouldn't be any reference to plain http at all.

Second, the DSL for Kube and Ambassador seem ridiculously complex for this.
Maybe some explanation for what "imagePullPolicy: IfNotPresent" means? This
kind of configuration harkens back to the myriad of Jboss XML files, just in a
different format. For me personally, I get all the reasons why you'd want to
use k8s, but for a "getting started" user, seeing this kind of required config
-- rather than sensible defaults hidden away -- would get very discouraging.
("Why should I learn this DSL instead of just making sure I had a correct
puppet setup?")

------
ealexhudson
I think this is an excellent introduction to the tech side.

I do sometimes think that "Getting started" articles should sometimes be
prefaced with a "here's who this isn't for" \- particularly with architectures
designed for scale not simplicity. I tend to think if you're in a situation
that demands microservices, you should already know the tech stuff :-) The
hard bit about getting started is really reconfiguring the team.

~~~
GiorgioG
I have to say I'm sick of the microservices fad. For the 99% it makes no sense
to incur the complexity cost because YAGNI unless you seriously plan on
scaling to FB/Google/etc levels...and realistically if your little app blows
up to that level, you can figure out how to break it apart into 'micro'
services when and where it makes sense to do so.

~~~
rdli
While microservices might be helpful for scaling from a perf level, a lot of
the situations where I've seen microservices apply is the _organizational_
scale challenge.

How do you get lots of engineers to work on a single monolithic application,
while releasing the app into production on a very frequent basis (e.g.,
daily)?

The traditional answer has been to add complexity into your workflow (e.g.,
feature freezes, staging environments, code reviews, more testing). These are
all reasonable things and good ideas. But at some point your velocity starts
to slow down dramatically because of all this complexity.

Worst of all, this complexity isn't necessary for every feature. You might be
prototyping some stuff, for example. But a monolithic architecture forces
everyone onto the same workflow.

Microservices enables different workflows for different features (services).
The value of this, even when you're at a small scale, can be pretty
significant.

~~~
zmmmmm
This is similar to why we are doing it ... our app is quite simple, with about
5 moving parts. But we need it to be able to keep running continuously while
allowing each part to be upgraded independently, and to be able to shut off
the valve of messages going to each part so we can upgrade it and test it
without bringing other parts down. Several of the parts share data models and
underlying code ... so perhaps they are not true "microservices" ... but to
the extent they are, for us there are some useful aspects to the fad.

------
scarface74
So tell me why I should prefer this over Consul for service discovery, health
checking, etc. and Nomad for running jobs? With Nomad, I can choose raw
executables, shell scriots, jar files, docker containers, etc. I can choose
batch jobs or long running services and the executables for each are less than
60Mb and they can serve as servers and clients.

~~~
techterrier
no reason at all, those are all excellent choices

