
Scaling Your Org with Microservices [slides] - kiyanwang
https://bridgetkromhout.com/speaking/2017/srecon/
======
joaodlf
If anything is trendier than microservices, that is bashing microservices.

Before this comment pool spirals into that, I'll just leave this: It all
depends on your project.

Did you have a bad time with microservices? Maybe the implementation was
wrong. Maybe the project doesn't fit the model. Heck, maybe the project would
STILL be screwed under a monolithic approach. There are so many variables to
what classifies a success/failure in the microservice world (like most other
things in software development, actually).

What's important is to not have a polarising opinion: "microservices suck",
"microservices should be used for everything". Analyse your requirements.
Imagine your professional project a few years down the line. Educate yourself
on the subject (there are books on the subject!). Make. Sure. It. Fits.

I've personally had successes and losses with microservices, just like I had
successes and losses with other architectural styles.

~~~
fma
I've taken a middle of the road approach often I've often seen recommended.
First build a monolith then split it apart logically when it makes sense. Not
really 'micro' but my application with 6 medium components is easier than with
one monolith, and easier than 20 micro.

Of course if I go to an interview I'll say I built microservices because it's
a buzzword/checkbox.

~~~
Clubber
This. Build monolith or SOA then shard off the pieces that are bogging down
the application, then node them out.

------
impostervt
I recently completed a "next generation" architecture prototype for a client
using microservices (that part was specified by them).

I developed a dozen microservices to mimic aspects of their existing
applications and used Kafka as a message bus. The services rarely spoke
directly to each other, but instead listened to events fired into the message
bus and updated accordingly.

My biggest takeaway - the client should not use microservices, but could learn
some other lessons from the prototype. Microservices make many things harder
and the only benefit to them, in my opinion, is they can scale well. But if
you're not working at Netflix scale, they're more trouble than they're worth.

What I did recommend: \- Build new applications API-first. By that, I mean
your front end UI (assuming you have one) communicates to your backend via an
API that can be exposed to the world. And assume it WILL be exposed to the
world.

\- Avoid bloat in your applications. Stop adding every possible feature to
your existing app, and pay attention to when it's getting too big. This is
mostly a gut/intuition feel, but you can tell it's a problem when your
developers start to look like a deer in headlights when you discuss a new
feature.

\- (optional) Do create an enterprise message bus, and each application can
fire events into the bus. This will help future-proof your organization, as
new applications can be built to listen for events without having to
understand the other systems.

------
staticelf
I have yet to see a good technical implementation of microservices. It always
seem to get messy, inefficient and hard to organize.

Everything seems so hard. To follow and debug requests for example. How do you
do that in a good way? Running a local microservice application is another.

Maybe microservices is good for very large corporations, but even then I am
not really convinced since it seems easier just to learn one bigger codebase
that is structured well rather than digging in to many different ones that may
be writter in different languages etc.

The hype is so big and the benefits are very unclear. At least to me it seems
like there are only negative aspects of doing microservices.

~~~
jdmichal
I always tell people: Microservices sacrifice _everything_ at the alter of
scalability. Everything but scalability gets harder, not easier. You point out
some good examples of places where this is true.

You should not be doing microservices unless you need that scalability. If you
don't, regular SOA or even modular monoliths work fine. Microservices live in
the place where those break down in scaling. That's a very extreme place, and
so microservices are an extreme response.

As an example, let's take scaling services over a hybrid cloud. You have your
own metal for the baseline request volume, with the capability to provision
more capacity from a public cloud. A modular monolith is obviously out of the
picture at this point. You would have two separate monolith instances, and
would have to consider how and when to pass work between them... Possible, but
at that point you're basically inventing a service architecture within a
monolith, so why not just move to SOA? If you already have a SOA system, you
still have work: Which services to deploy to the cloud, when to deploy them,
how to recover and load balance to them, etc. Specific answers to these
decisions are what led to what we consider modern microservices: What to
deploy is the smallest unit possible, so that you can keep scaling as fine-
grained as possible. Every request is routed through a discovery and load-
balancer to any and all available instances.

~~~
jules
What do you mean by scalability?

~~~
jdmichal
That's a great question. I mean ability to serve concurrent requests, or
throughput. Microservices will typically worsen other metrics like individual
response time.

~~~
jules
I am not sure microservices are good for scalability in that sense.
Microservices divide your application vertically, but for scalability you want
to divide it horizontally. You don't want a separate service for each feature
of your app, you want an application server that you can replicate as many
times as necessary.

~~~
jdmichal
Microservices can scale both directions, same as other systems. You can
allocate more resources to individual service instances (vertical), and you
can allocate more service instances (horizontal). The later scaling should be
done in an automated fashion.

If you look at something like Spring Boot, you will find that an individual
service instance _is_ a stand-alone application server. That is what is
duplicated when a new service instance is created.

------
aaimnr
From TFA: "I don't think anyone should approach management as a thing they
move in to permanently. It's psychologically disfiguring."

Such a great quote. The longer I only do management-only work, the more
anxiety creeps in silently about not being able to do these things on my own,
not being competent enough, being a fake etc. The moment I decide to solve
some problem for myself all is cool again - and I'm more trustworthy for the
team as well. The problem is that such an approach tends to create conflict of
interest - as a manager you shouldn't interfere too much and allow the team to
solve the problems. Maybe the notion of manager is a problem in itself. It's a
tempting perspective, but as far as I remember Google thought so as well and
at some point they had to step back and reintroduce classic managers again (
[https://hbr.org/2013/12/how-google-sold-its-engineers-on-
man...](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management)
).

------
Areading314
Incredibly cringey presentation...

"Hard things are HARD", etc. plus a bunch of memes and my little pony
pictures.

------
msoad
Micoroservices are great for _RUNNING_ your app, monolithic are great for
_DEVELOPING_ your app. I wish there was a way of developing like a monolithic
and deploying like microservices.

Monolithics are good because you get a "stack trace" of an error! That stack
trace is so much better than all that Ziplin stuff that barely work and takes
so much longer to just see what caused the error!

------
subru
Someone eventually is going to build an app framework that offers clean
reusable abstractions for micro services in the context of a further-
abstracted orchestrated and containerized provider-agnostic automatically
highly available and scalable infrastructure, complete with backup, security,
log analysis, and all open source and installable through a single remotely
executable shell script.

------
dastbe
to me this slide deck is "how to not completely fail at getting a minimally
viable microservices arch going in your organization" which is good because
apparently these lessons are not self-evident. But when are we going to get to
"now that you're a healthy microservice company, how do you make it better?
For you and your customers?".

I guess I would take the recent honeycomb outage as an example since charity
majors in on the slides. When reading through the post mortem (which I liked a
lot) the one question I never had answered was what are they doing to make
sure 1 customer can't take down the entirety of their service? Assuming that
failure is going to happen (via code bugs or bad actor customers)how do we
better isolate individual customers from one another while still enjoying the
benefits of mulitenancy? As we as an industry become more comfortable with
microservices we must also learn how to better serve customers and mitigate
failures by isolating and limiting blast radius, as well as deploying software
in safer and saner ways.

