
Microservices, Containers and Kubernetes in Ten Minutes - old-gregg
https://gravitational.com/blog/microservices-containers-kubernetes/
======
thinkersilver
There's so much to comment on in this article. First off gravity looks like an
interesting product, it's shame a blog article on that hadn't made it onto the
front page.

I hate to be nit-picky but I do feel that articles like this do more harm than
good by oversimplifying a fairly advanced architectural pattern by downplaying
the testing, resiliency and deployment approaches.

* easier to test - this is flat out wrong. Your application or system logic is spread out across multiple process boundaries - the only way to test it, is to deploy the dependent services on your dev machine and test the set or design your services so that all the application logic can run in a single process. Think spark and spark workers that move from a thread to a distributed model through configuration. Application logic can be tested with this approach, but not necessarily system behaviour (which can be simulated)

* rapid and flexible deployment models - in a large microservices fleet where code is managed by multiple teams and sits in several repositories the dependencies are not explicit (I can not do a "find usages" on a API call and see all microservices that are using it) - so deployments can be decoupled but there tends to be lots of breakages unless you have sophisticated well-thought out testing (see first point).

* resiliency - I'm not going to expand on that because 1st and 2nd point allude to a brittle system and hence reduced resiliency. There's also data and transnational boundaries across services which need to be addressed to. To be fair, there is a hint to solving this problem through something like kakfa but it isn't called out.

Microservices can be simpler with good tooling. Kubernetes is only a very
small part of it. Maybe a follow up article may be good to clarify on what
tooling can be provided for 1) better testing 2) reliable deployments 3)
greater resiliency.

~~~
ljm
To me, this isn't nit-picky, but nuanced. From my experience Kubernetes and
the microservice architecture is essentially a technical substrate for an
organisational problem.

I'm not 100% convinced there's inherent technical value until you're running
at the kind of scale the big hitters do, but by then you're also looking at
the hosting solution as a whole, not a deployment in a cloud. Docker,
Kubernetes, offer the illusion of being easy but as soon as you start getting
serious, they are anything but.

What it does do, for smaller businesses, is create a more-or-less 1:1 mapping
between a team structure and a deployment pipeline. At the end of it you're
distributing functions in a codebase and depending on the network for
resiliency, as opposed to the language or the VM.

At the same time, the knowledge of these systems has great value because those
skills are in demand now.

~~~
tracker1
Docker and/or Dokku are pretty simple and easy to get running. When you
outgrow a single-server deployment, that's when it gets more complicated. I
like docker in general because it allows me to test/script creation and
teardown, even locally.

The biggest short coming right now is that Windows support for both Windows
and Linux containers (LCOWS) is really immature, and Windows containers in
particular isn't mature enough at this point. I'm dealing with this for some
testing scenarios where containers are simpler than dedicated VMs.

------
dagss
It is possible to build balls of mud either with microservices or larger-sized
services.

There are pros and cons to both.

But when "easier testing" (from OP) is said to be an advantage of
microservices specifically...I am not sure what to say.

I mean it is not like every test has to test the entire monolith. And it is
not like testing each microservice in isolation is always going to be
sufficient.

It is entirely orthogonal. Of course a well-designed microservice is easier to
test than a monolithic ball of mud, but a well designed monolith is also
easier to test than a poorly designed spaghetti of microservices.

It is as if some people think "good code" and "microservices" are synonyms.
No. They are orthogonal.

Industry is always going in circles. Fads come and go.

In many ways, Cloud Functions are very similar to a horizontally scalable
stateless monolith backend. When you break up services small enough, the
"monolith" arises again as simply the sum of what you deploy in an
organization.

~~~
colonelpopcorn
It just goes to show how few folks truly test in isolation.

~~~
quickthrower2
I don’t always, but I’ve never had the luxury of working on a greenfield
project. With legacy code it’s a mammoth task to pull apart the spaghetti
(more like a drawer of tangled headphones) to get the ideal test.

------
Datenstrom
> In fact, you may discover that you already have a dozen of microservices
> deployed at your organization.

Very true, robotics/avionics/etc. have been using "microservices" for a long
time, nothing new here. Robot Operating System (ROS), Data Distribution
Service (DDS), Lightweight Communications and Marshalling (LCM), and others
all encourage that architecture.

~~~
justinsaccount
Yep... any enterprise is likely full of them:

    
    
      ldap: authentication microservice
      syslog: logging microservice  
      smtp: messaging microservice  
      smb/nfs: file storage microservice
    

They haven't been called that for the past 40 years, but that's what they are.

~~~
Thaxll
Except that they don't really talk to each other and if they do it's using
custom protocols. Also I wouldn't call those "micro".

~~~
sbov
A microservice doesn't have to be micro! They are oftentimes a single bounded
context in domain driven design, which can be huge.

~~~
newaccoutnas
So, a service, then?

------
rolleiflex
The main question I've always had about microservices has been, how do you
handle services that are truly depended on by all other services? For example,
the authentication service is depended on by pretty much anything else.

This is not a hypothetical question — I'm actually looking for a better way to
solve this right now in Aether's business infrastructure right now.

~~~
thorgaardian
This is a problem I've seen at every company I've ever worked at. Everyone
starts off thinking they'll have independence, but it's only natural to build
on what already exists and thus you end up with complex dependency topologies.

Large software companies like Google/Facebook home build their own opinionated
frameworks for publishing services that include citing of dependencies via
config files. Internal engines then scrape for these configs and manage the
relationship topology across environments. As far as SWEs are concerned its
like magic.

I'm working on trying to standardize such a framework,
[https://docs.architect.io](https://docs.architect.io), and would love
preliminary feedback.

------
pilif
_> higher overall resiliency._

yes. because making a page render dependent on the availability of 10s of
independent network services is going to greatly improve your resiliency.

I guess it's a matter of perspective.

If you are willing to count a partially working experience as still working,
then yes, you might be able to say you're more resilient because only, say the
service to add a product to the basket is down - you can still look at
products, so technically, you're still up.

That's not how availability is measured normally though. In my (and definitely
in my users) book, a site where some stuff is broken is broken. Period.

And if that's the environment you're working in, you're really not improving
matters by adding unnecessary network layers between components of your
application.

------
peterwwillis
When you should use microservices: when you have many independent two-pizza
dev teams. (If you live in Pittsburgh, three-pizza teams...)

~~~
myroon5
I'll bite. Amazon Pittsburgh office inside joke?

------
gdulli
> Small projects should not shy from the monolithic design. It offers higher
> productivity for smaller teams.

Yes. In my next job search I'd like to find a way to feel out a team for
whether they adopt new patterns reflexively and dogmatically vs. consciously
and contextually.

------
rconti
The Amazon example reminds me of a former coworker telling me about how their
processes ran back in '99-ish. Every webserver process was huge (128MB sticks
in my head, if I have the period-correct units straight), and only lived for
the length of the session before being terminated, due to memory leaks and the
like.

------
chuhnk
If you want to build microservices on top of kubernetes I'd recommend go-micro
[https://github.com/micro/go-micro](https://github.com/micro/go-micro)

------
coleifer
How do you want your spaghetti served? Baked-in the code, or the rpc variety?

------
mtarnovan
You should not ask: "When to use Microservices?" if your previous question
was: "What is the difference between microservices and containers?"

------
nfrankel
> Small projects should not shy from the monolithic design. It offers higher
> productivity for smaller teams

Wow. Has the author any real-world experience from using micro-services? Or is
it just word-of-mouth? Because I have a complete different take on this.

------
devcriollo
example code ?

~~~
CodeMage
There isn't any. This is essentially a thinly disguised ad for Gravity.

~~~
rafaelgoncalves
exactly, code sample would help on this ad feeling, for me diagrams are too
abstract.

------
mathie25
very good explanation!

