Microservice Trade-Offs
martinfowler.com
martinfowler.com
And then when they need help fixing the mess they can call in a consultant wielding Fowlers latest book, or go to a bunch of new monolithichitecture conferences where people put up slides full of memes mocking microservices.
Truly we are blessed to live in an era of such efficient job creation.
If yes, please, create a library.
Microservices share data, if you'll need part of the data in other projects, yes, they are the way to go. If you just need behavior, or need to decentralize CPU usage, there are plenty of easier ways to achieve those.
Assuming you want to force everyone to use the same technology stack. And redeploy every application every time the internals of the library change.
That may well be OK for what you are doing. Or not.
Also, a library does not force people into the same technology stack. It makes it easier to work with the same programing language, but it's still possible to not do so. Microservices also often have complex data structures that only work well when created and parsed by the same set of tools. There is some difference, but much less than you are claiming.
Personally, I would start sooner than that. I think new technologies make service creation easier. But the right moment for me depends a lot on product, team, and tech.
So I guess I would say that any place not working like that might not be ready for a microservices approach.
I think Containers are somewhat pushing Microservices a bit too early for some organizations because of Docker's focus on single entry point (sans supervisor, etc). They are useful for other reasons, but containers solve people problems, containers solve technical deployment problems.
You don't want N kinds of things if you can have 2 kinds of things (say, web tier, job workers for long running stuff, db layer), until you start having problems working out of the same codebases/repos/etc.
Microservices make things harder to debug and most likely there is still coordination that needs to happen, and it's likely going to be less efficient versus developing libraries -- so if you're a small company, you can probably ignore these for a while.
We've also all met that developer that decided that Foo (library, framework, pattern, language - pick your poison) is SO MUCH BETTER than Bar (which is what you use now), and frantically sets out to replace all things Bar with Foo (and gives up halfway, so now you've got the maintain both Foo and Bar bit of your code, all intertwined).
The problem isn't with Foo and it's merits, it's actually very useful, the problem is that that developer is, frankly, shit.
Microservices is a perfectly useful pattern to achieve a number of ends, but it's not the answer to all questions. Know what you're trying to achieve, evaluate options on their actual merits (not what's buzzwordy this month) and make decisions consciously.
EDIT to add:
> can I see parts of this project being used in another project?
That's not the only benefit from microservices. Smaller units are easier to reason about (and test!), and they allow you to experiment: A monolithical app needs to maintain some sort of consistency. Most of the time it will be written in the same language, using the same general patterns and libraries supporting these patterns (eg. dependency injection using Guice or Spring). Most of the time, none of this will be cutting edge, some of the time it will be decidedly out of date, but changing it is hard and risky, and, well, it works.
With microservices your can use the languages, patterns and libraries that suit your isolated use case best. Need to support complex web forms? You might want to run Node.js so you can use the same JS code for validation on the front end and back end. Need lots of boring CRUD in your admin app? Ruby on Rails is your friend. Number-crunching? You might want to use Clojure or F#. Interfacing with some proprietary system (e.g. Sharepoint)? Use the best supported library you can find (.NET webservices client), and build a service up around that, on the platform that best supports that library (ASP.NET on IIS on Windows).
First, you need to issue pull requests for multiple projects and keep mental track of the status of those pull requests.
Second, [in a large organization] you might find out that changing the microservice on the server side breaks some client down the road because of new/unexpected parameters introduced, and the client handling it poorly.
Third, if the services [in a large organization] are distributed across multiple teams, you need to work around their schedules and their deploy calendars to orchestrate those changes.
And if you're having a tough time deploying changes, it sounds like you're not practicing continuous delivery, which as Fowler said is a prerequisite.
Patient: "Doctor, when I bend my arm backward, it hurts!"
Doctor: "Stop doing that."
- don't issue pull requests for multiple projects
- don't keep mental track of the status of those pull requests.
- don't worry about breaking clients
- don't worry about the logistical/scheduling issues of multiple teams
?
I think the idea is to use microservices when they will be owned by separate teams. If your application is small enough that a single team can meaningfully work on it, then you probably don't need to break it up.
There's also the question about project complexity.. does the marketing website really need to be part of the application's project?
It's a matter of separating things out where it makes the most sense.
Experienced engineers know that technology that has stood the test of time is boring. But we are not in the business of designing "fun" ways of working constantly, we are here to ship software on schedule and produce something that is easily understood and maintanable by next generation of engineers, instead of getting bamboozled by a new buzzwords invented by empty suits (agile, tdd, xp, microservice, mvc up your browshizzle), regardless, if not an engineer, than some "manager" who can't code reads some article on HN, and decides that's the way to do it.
That said, I heard a dev want to break up a low traffic app that had to take in a message, encrypt it, then put it on a queue want to break that into microservices. My first reaction is "what the fuck?". My second reaction is that an encryption service might not be a terrible idea, though I doubt ensuring folks don't roll broken encryption is why the dev proposed it.
If it worked "perfectly fine", and the team is productive, then they should have spent their time on more important things :).
To reduce complexity and centralize common functionalities API Gateways such as KONG (https://github.com/mashape/kong) are the base of microservice architectures.
No, it's not appropriate for your blog. But it IS appropriate for many applications out there and it's an incredibly beneficial way to scale a set of services and build a complex application in a cost effective manner.
I don't quite agree with the notion of being "stuck maintaining five apps, five APIs, etc." because it's not. It's really one app. You're doing something wrong if you feel that you have five different apps and APIs. In fact, your testing and debugging should become easier under such an architecture. Maintenance should be much better if done properly. Of course regardless of your software architecture, you can end up in "maintenance hell" so that's really an invalid argument against SoA. I certainly wouldn't let the fear of bad programming prevent me from using a specific design pattern or architecture.
I gave a talk about MWRC 2015 about this: http://brianknapp.me/message-oriented-programming/
Micro services are simply a physical boundary to enforce discipline between logical modules.
It is a solution to a symptom rather than solving the root causes.
Alcoholics don't keep booze in the house either. That's treating a symptom, not a cause, but it's effective. And yes, I did compare programmers violating interface boundaries to alcoholics.
Yes. My current enterprise client takes a week to deploy their micro service arch. Because all systems need to be deployed at once.
So, they simply traded one complexity for another without fixing the root problem--a disciplined development methodology.
>> Distributed systems are harder to program, since remote calls are slow and are always at risk of failure.
This is a true statement, but it's hardly the point on which current architecture choices turn. Distributed systems are the norm now. Almost everyone is working on one, even if they don't think of it that way (and I bet they don't). There are still simple, single-process programs that are relevant to users and the people working on them, but those aren't the domains in which this microservices debate is supposed to be taking place.
Is it relevant to evaluate "microservices" vs. a "monolithic architecture" based on the costs of traversing the network stack? Back when we were thinking about breaking up our C and C++ programs into processes using RPC as glue this was something we worried a lot about, but that is because in many cases having everything in a single process was still a credible alternative. Few people are wrestling with this choice today.
The last site I worked on consisted of nginx, elasticsearch, logstash, kibana, postgresql, celery, redis, and a bunch of custom python, java, and javascript code. It could run on one server or (as it did in production) twelve. Almost all of those pieces ran in separate processes, communicated over the network using mostly standard protocols, and did one specific thing. Were these microservices?
I feel like microservices as a thing is one of the least meaningful tech fads I have seen. Minimality and cohesiveness aren't surprising new challenges. They were desirable concepts of C++ class libraries two decades ago. An implementation of a service should always be both minimal and cohesive, and it should be complete. It should be as small as possible. Whether that is "micro" or not is entirely too subjective for me.
The other trade-offs mentioned, consistency and complexity, are not much more relevant to the big question the author is trying to convince us to ask. Consistency is a property of a view of state, but the article is about distributing code (otherwise why care about module boundaries and deployment?), not distributing state. Complexity is always a a key trade-off, but the complexity of distributed code is table stakes in the world we actually work in.
> since remote calls are slow and are always at risk of failure.
Talking to e.g. MySQL is a remote call too, that can fail just as easily.
To avoid increasing complexity in managing all these APIs we have added KONG [1] on top, so we can keep higher consistency and orchestrate common functionalities among multiple services. In some ways it's funny, because KONG "centralizes" a decentralized architecture but we needed one home base to always refer to or rely on,when most of the system started to live on the edges.
In space explorations you always have a mothership after all.
As for "microservices", part of the problem is that the UNIX/Linux world has historically sucked at interprocess communication. Everything looks like a pipe, and you have to build something that works like a subroutine call on top of it. (Yes, there's System V IPC, which nobody uses.) The mismatch there results in much overhead associated with framing and such. Also, because the IPC and scheduler aren't integrated, each interprocess call tends to put either the sender or receiver at the end of the line for CPU time. This can add huge latency to service calls.
I've written hard real time code for robotics on QNX, which has a good MsgSend/MsgReceive system for calling other programs. Message passing and That works out quite well, especially when some programs run at higher priorities than others and have hard time constraints. QNX doesn't have a really good system for starting up a set of programs and getting them communicating, though; I had to write something for that.
One lesson from QNX is that marshalling and interprocess communication should be separated if performance matters. IPC done right is fast, and marshaling done with code generated for each message format is fast. Generalized interpretive schemes like CORBA and JSON-based systems have much higher overhead than a subroutine call.
Another lesson is that better tools for managing groups of programs are necessary. It's a hard problem. Look at the "initd" mess. That's just a special case of managing a group of microservices. Just getting everybody connected up securely at startup is hard.
What about Datagram UNIX sockets using sendmsg/recvmsg? I've implemented a simple RPC using them and it seemed fine.
In the Java world there is the idea that you make interfaces for services and then a dependency injection systems decides which ones to create at runtime.
Many useful microservices can be implemented with a key-value store, and this could be implemented with anything from an in-memory Hashtable or something that uses the disk or off-heap memory or runs in a huge distributed cluster.
In that case you get to use in-process when it is expedient (like literally, you cut power and latency if you don't waste time turning floating points numbers into strings and whatnot.) When out-of-process makes sense you are ready.
To accompany this you need frameworks and tools that eliminate a lot of overhead, for instance, to automatically generate the stub code for service calls, manage a large number of servers, etc.
We do the same thing in Go, C#, ...
Why microservice I am very specialized, and every service should do just one thing well, think about send an email, load the ads or load the comments.
Why we don't build a very shallow service, that does everything for just a very small part of the website ?
In a classic website a micro monolithics (mm) could be something like "/login" or "/post-picture".
The mm will not call any other service but it will be able to do every action by itself.
Simply deploy a (or more) new service for every (busy) end point of your application.
In this way we can share, or isolate, our codebase.
It would be easy to deploy, basically you are simply using a whole server to run one single function at very high frequency.
It can bring a lot of chance for optimization.
Just thinking...
Makes me think of https://news.ycombinator.com/item?id=9777567
I've been working at Giant Swarm[1] for the last few months as the evangelist. Our original intent was to focus on providing a PaaS-like containerized stack in a multi-tenant/public cloud offering; something that felt a bit like Heroku, but less restrictive stack-wise. We're now engaging in a few professional services deals, given the high demand for an easy-to-deploy/easy-to-run container system.
I think the high demand we are seeing in the ecosystem is coming from organizations/individuals who want to understand how to use and deploy containerized stacks. I see the primary problems being people are unable to keep up with the innovation in the space (drinking from a firehose) and are unable to find the properly skilled labor force to implement a solution (training/expereience lagging behind demand). That observation would directly relate to Martin's comments on operational complexity.
I will note I observed a similar phenomenon with OpenStack, so my observations are certainly not an indicator that people will be using these deployments initially. It will likely take some time before microservice-based develplment is a common pattern in larger organizations. At the very least, they know they need to be thinking about it...
Seems like most of the tooling now focuses on automating small parts of dev and ops teams' workflows, instead of looking at the larger picture of organizational tooling. I would guess that in a few years we'll see a lot more PaaS-workflow solutions focused on abstracting away a lot of the operational complexity of microservice architectures, reducing the barrier to entry for "maturity" of dev/ops teams, just like AWS & co reduced the need for people to really understand server hardware.
Fast forward to today we have essentially jars and Dlls with the added overhead of an entire system and deployment to maintain.
Boy have we gotten things wrong in this industry.
Or maybe this exists and hasn't got a lot of press. Or it has been tried and failed.
http://blog.plataformatec.com.br/2015/06/elixir-in-times-of-...
My rule of thumb when deciding whether to deliver a piece of functionality as a service is "Will another application/system/whatever ever want to be able to use this functionality?"
If the answer is yes, that would be a fairly compelling argument for implementing it as a service. If the answer is no, then the question becomes "Why not implement it monolithically?"
It seems a lot of people confuse "microservice architecture" for "loosely coupled architecture".
edit: accidental reply click
First, you learn about a cool new thing, understand it and it's limitations well, and advocate it as an improvement: https://www.chrisstucchio.com/blog/2012/bandit_algorithms_vs...
Sometime later, you realize that people are using it well beyond it's domain of usefulness and "backpedal", i.e. try to make sure the limitations are also well known: https://www.chrisstucchio.com/blog/2015/dont_use_bandits.htm...
The compromise you have to make to have a micro service architecture doesn't make sense for anyone else other than Google or Amazon or extremely large organizations.
Even with such architecture in place, you are going to end up with far more overhead by using microservices, it simply isn't the case that by isolating individual components into functions, you suddenly get productivity.
It just infuriates me when engineers or product managers bored with their job constantly invent buzzwords to confuse, increase complexity, end up failing, and back to just regular old boring tech.
If it ain't broke don't fix it. Why the fuck would you want to now have 100 different API end points to do something that would've taken less than 50 or so lines of code? This doesn't make sense for 99% of software companies out there.
They damn well will get a lot of benefits from microservices for their newer capabilities... IF they also work on the operational aspects (continuous delivery, a devops culture, and some kind of automated operating platform).
No one sane is publically advocating building microservices for a single team small app.