
Creating a Microservice? Answer These Questions First - kiyanwang
https://datawire.io/creating-a-microservice-answer-these-10-questions-first/
======
WestCoastJustin
If you are thinking about going down the microservice path, then do yourself a
favour and read _Building Microservices_ (O'Reilly) [1]. It is a little wordy
but lays it down pretty well. I'm not affiliated with them, but do heavily
research this space, and the larger ecosystem. I found it pretty well rounded.

I'm not sure this articles 10 question list really covers the scope of what
microservice means. For reference, I'm not talking about ~5 microservices here
(as that might be trivial), but am thinking in the scope of ~50-100+. In that
you should have a pretty good reason to adopt them re: your team size and
scale of operations. You can see an increased rate of deployed changes,
performance boosts, and freedom to choose languages that fit the problem, but
it comes with additional operational complexity. In that, you will pay an
upfront tax for using microservices. So, you really need to think about asking
yourself these types of questions (and the ones in the article).

\- How and where should you break things into microservices (if monolith)?

\- Who should own the microservice? What does this mean in terms of coding,
testing, deploying, ops issues, etc?

\- You will need team buy in. A switch could mean months of work. The upside
is massive but you cannot push this on them.

\- How do you deal with things at the datastore level (can/should two
microservice access the same table space)?

\- How are you going to deploy microservice via CI/CD pipeline into your
production env?

\- How do microservices communicate (RPC, API, etc)?

\- What type of metrics do you build into your microservice?

\- How can you trace requests when they hit multiple microservices?

\- You'll need to beef up your operations tools to manage these microservices
too. What does that look like?

These are pretty fundamental things you need to think about and the book does
a pretty decent job at explaining it.

[1]
[http://shop.oreilly.com/product/0636920033158.do](http://shop.oreilly.com/product/0636920033158.do)

~~~
musha68k
TL;DR buy the book it's great!

I'll second that, can't recommended the book enough. It will tell you exactly
_why_ and _when_ you should go down the microservice rabbit hole (at this
point). I'm saying at this point because there are still _many_ angles to this
(actually by paradigm) and lots of tooling surrounding it which are not quite
there yet (including most prominently docker & co).

 _Don 't fall for the admittedly great modern devops/open-source marketing._

I've been doing both application development as well as good-old systems
administration (xen, jails, openvz) for many years and believe me this stuff
is still _very_ resource intensive even with the help of other similarly
experienced peers readily available. We are literally talking google-level
infrastructure architecture, which of course is both bad (setup time) and good
(much more flexible and often "simpler" to grasp when the whole flow is
established).

While I'm still not at the product stage with my two microservice projects
started in August and September (both explicit microservice customer requests,
mind you) a friend of mine meanwhile has single-handedly been building two
monoliths over the last couple of months. He's been leveraging the still
undeniable king-of-web-app-productivity-combo of rails/heroku and is about to
move on to his next project while his customers are down the "let's polish
some more" beta publishing-angst.

 _Microservices are fun and they are an important development in our field for
many use-cases but be an engineer and pick the right tool for the right job,
already - educate your boss, peers or customers about the importance of seeing
things more objectively!_

Also, don't succumb to the macho "You must be this tall to use microservices.
OK, challenge accepted!" like I have to admit to have fallen for myself (I
readily obliged to going forward with the tasks at hand) - the cards are
largely stacked against you, most certainly when you are alone or not well
connected!

[http://martinfowler.com/bliki/MicroservicePrerequisites.html](http://martinfowler.com/bliki/MicroservicePrerequisites.html)

------
willejs
Real question: Do you need to build a micro service SOA right now?
[http://martinfowler.com/bliki/MonolithFirst.html](http://martinfowler.com/bliki/MonolithFirst.html)

Distributed systems are hard, and building a microservice SOA that is
functional is damn hard.

I feel like a lot of people are on the hype wagon of Docker and Microservices
right now, they arnt building products, but instead bike shedding with
technology decisions which are often not fit for their application. A lot of
the people reference to Netflix, Amazon etc, who are companies who had real
issues, real traffic, and real products and a real reason why they evolved
into a microservice SOA.

Other people reference half finished non production implementations, or people
like Hailo who took 2 years to build a technically impressive MicroSOA,
replacing their PHP/Java stack, whilst their product stagnated and business
declined.

------
hassy
I'd like to plug an open-source project that I've been working on here -
[https://artillery.io](https://artillery.io) \- as it relates to point (6) in
the article. It's a load-generator, and while it's not microservice-specific
per se, it's a lightweight tool that's quite easy to use and it lends itself
well to being used frequently, which is great if you want to start doing load-
testing early on during development (which is something I've started doing and
had good results with). It has HTTP and WebSocket support out of the box, with
AMQP coming in the next release (which is often employed as microservice
glue).

------
s_q_b
Sooo... Can somebody explain to me the difference between microservices and
Service Oriented Architecture?

~~~
WestCoastJustin
I think of microservices as an implementation of SOA. Guess that is not that
helpful, but it's almost like a battle tested guide on what the best way of
implementing SOA is via trial and error. If you look at how startups are using
microservices today, you will find almost a blueprint or common theme coming
out. Use an API, embedded metrics in the microservice, how to do monitoring,
tracing, use CI/CD, app+dependancy packaging, operations tools, etc.

~~~
mseebach
FWIW, it seems early SOA placed a lot of emphasis on the bus and the
middleware[1], with the problem being solved having more to do with enterprise
governance[2], not one of software architecture. It seems to me, true scotsman
and all, that modern micro services architecture has emerged from a first-
order attempt to solve actual problems around both scaling vertically and
collaborating on large systems in large organisations.

1:
[https://en.wikipedia.org/wiki/JBoss_Enterprise_SOA_Platform](https://en.wikipedia.org/wiki/JBoss_Enterprise_SOA_Platform)

2: "OMG how do we keep track of all the stuff running on all the servers?
Multiple versions, multiple languages, multiple OSs? This sounds really scary,
no, leaving it to the nerds is not an option, think of the BUS COUNT!"
(caricature).

~~~
UK-AL
We use NServiceBus, and Microservices for a lot of stuff and its really helped
development. It handles retries(for network unreliability), transactions, and
monitoring for us. Generally most of the issues of distributed systems.

------
Rauchg
> On the other hand, verifying the quality of a whole application that is
> composed of many microservices can represent a significant amount of testing
> complexity: instead of running a single command to test the code running in
> one process, a large number of integrated dependent components must be
> running first, verified as healthy, and stay running throughout the tests.

This was very likely already the case for the monolith as well. It likely
depended on databases, caches, queues, etc. The solution is the same in both
cases: an orchestration solution (such as
[https://docs.docker.com/compose/](https://docs.docker.com/compose/)).

~~~
skewart
Maybe. But, setting up the monolith locally is documented in one README, and
you've probably already set it up. And, depending on how big your org is, the
monolith probably has a lot fewer different databases and caches and queues
than all your various microservices built by different teams with different
preferences over the years.

Obviously there are solutions to this problem, like you pointed out. But ease
of integration testing - both manual and automated - is one thing you often
give up when you go down the microservices path.

------
strictfp
11\. How can you refactor your application now that you modularized it so very
aggressively?

~~~
rdli
Refactoring occurs in similar ways: with strong interfaces between each of
your microservices, you can change the implementation of your individual
microservices (e.g., keep the payment processing microservice interface the
same, but change the internals). Or you can also change which microservices
get invoked (e.g., switch from v1 to v2 of a given microservice).

~~~
strictfp
Yeah, but you do prevent refactorization across service boundaries. I feel as
if you should really think twice before cementing your architecture like that.

~~~
rdli
Can you give me an example of why you can't refactor across service
boundaries? In my mind, refactoring a service interface is the same as
refactoring the interface (API) of an object. It's real work (tm) but
definitely do-able.

~~~
douche
All things are possible...

I would imagine it's more a question of risk. If you're changing an interface
_inside_ your application boundaries, you can figure out pretty easily where
the changed API is called and what you've got to do to fix it. If it's
something on the edge of your microservice that is public, so who knows what
unknown bits of code are open to breakage if you change your API, that's
harder to track down and fix.

I don't know a ton about actually implementing this sort of thing, but from
the outside looking in, this seems to be a common reason for API versioning.

