30 ms·

The End of Microservices

258 points by reimertz 10y ago

EGreg 10y ago
John Titor is back!!
- stephengillie 10y ago
  Did he bring back the IBM 5100 that he promised? https://en.wikipedia.org/wiki/John_Titor https://en.wikipedia.org/wiki/John_Titor
msoad 10y ago
One thing I don't like about SOA is that an error does not have a full stack trace. I know Zipkin exists but it's nowhere close to what we had in a monolithic app where you could just put a breakpoint and trace back to where exactly an error is thrown. If we can find a way of running a giant monolithic app in development and production environment without vertically scaling our machines, I would rather have that. Every bug I'm working on is like a mystery that I have to hop to many services to find what's going. I also think HTTP is the worst protocol for apps to talk to each other.
- malandrew 10y ago
  http://opentracing.io/ http://opentracing.io/
  - slowmovintarget 10y ago
    I was thinking of a simpler "Y U no log?!?" with correlation IDs but this is much cooler.
- themihai 10y ago
  Depending on your requirements micro-services may be a good or a bad solution. If the communication/protocol becomes too chatty that may be a sign you are doing it wrong.
- jeremiep 10y ago
  How is that different from debugging a multi-threaded or networked application? In both cases barely entering the debugger changes the behavior of the system. Heck even an asynchronous program running on a single thread doesn't have full stack traces. Having worked with both monolithic and SOA apps, the later yields radically simpler architectures and from there you spend a lot less time debugging. The older I grow as a programmer, the more I dislike monoliths. I'd rather have simpler programs where entire classes of bugs are guaranteed never to happen. I have yet to see a single monolithic app without serious technical and conceptual debt. The worst thing is that back when I thought monoliths were great I had absolutely no idea things could be so much simpler. Also, HTTP/1.1 is a fantastic protocol. Its dead-simple to implement, debug, cache, send through proxies who won't understand your custom headers or body format and whatnot. It even gives you an extra layer of routing on top of TCP/IP! This is exactly what you want to build systems with.
- uluyol 10y ago
  What's wrong with HTTP? If you're going to build an RPC protocol, you are going to need encryption, stream multiplexing, a way to distinguish RPC methods, support for extensions (e.g. auth), and compression. Add the fact that high performance HTTP servers and clients exist in most languages, and building an RPC protocol on top of HTTP sounds pretty attractive. No wonder gRPC did exactly that.
  - devonkim 10y ago
    Tons of round trip calls potentially in most RPC-style systems are one start, which Cap'n Proto addresses with its unique style of avoiding round-trips for many network transactions which can drastically reduce network chatter. Security is addressed simultaneously (but not necessarily sufficiently for many people or regulatory bodies) in Cap'n Proto at least via use of capabilities instead of building it into transport layers.
- RhodesianHunter 10y ago
  Any service taking requests from a client generates a UUID and passes it through to any additional services it calls. Most microservice frameworks have this functionality built in. You log to a central store such as an ELK stack or any of the great third party offerings. When you need to see the entire stack trace you search by the id.
- djspoons 10y ago
  Tracing and debugging-in-developer are solving different problems, though: tracing is there to help you understand issues that you can't reproduce in development. And for the record, Zipkin is only one tracing tool and is really aimed at helping you address latency issues, not errors.
sinzone 10y ago
When this year I came back from Dockercon I immediately wanted to write something very similar to what this article describes. I wanted to imagine a world where Containers and Microservices were part of the past already, and so I wrote "DockerCon 2020" [1] and how it will look like. [1] https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz3pruf4 https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz...
stevehiehn 10y ago
Maybe a more appropriate title could be 'Microservices are the Norm'
- brianwawok 10y ago
  I don't think they are. I would be surprised if 10% of new code right now was coded in microservices.
  - stevehiehn 10y ago
    Ya, you're probably right. Its likely just my bias. It feels like its the only thing i encounter at my day job.
- spriggan3 10y ago
  In S.F. startups maybe, not in the enterprise world. Enterprise is barely SOA today, they aren't going to throw 10/20 y.o. apps that still work for the latest fad. Just like MongoDB didn't replace Oracle or SQLServer just because it was hip.
  - brightball 10y ago
    The enterprise world I lived in was all SOA 10 years ago. WSDL services everywhere.
tuananh 10y ago
They have the word "microservice" on their homepage :D
dasil003 10y ago
Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that scales to large companies. Once you get to dozens of engineers and millions of lines of code you will inevitably need to have an SOA because Conway's law. Also, there is a learning curve to building microservices which improved tooling really helps with. However the thing that really grates at me is how these articles say things like: > Services are now an everyday, every-developer way of thinking With nary a mention of the overhead. There is no way around it, distributed systems have an irreducible complexity no matter how good your tooling and boilerplate is. You have to put in extra work to decouple everything and handle failure in a way that actually reap the benefits of the distributed system. And in the end, what these articles always gloss over is the interface between these systems. If you can easily define an interface between systems that stays relatively stable as the service evolves, then congratulations, you have a good candidate for a service with minimal overhead. But for most applications, those interfaces are shifting all the time, and there is no better tooling than multiple logical services running within one binary and build system where integration testing and validation is cheap. This is a real fucking problem people, it's not going to go away because there's a couple billion dollars worth of venture-backed startups ready to blow their cash on you in the vain and most likely misplaced hope that they are actually going to have to scale to dozens of engineers. Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now.
- pm90 10y ago
  This is a great point. I don't think the hype is due to a fad alone. There are a lot of good reason why microservices are much easier to create and deploy today: containerization and the associated technology around it. This makes microservices a very natural paradigm for app deployment. Of course, its not a holy grail. But we see that kind of thing over and over again. I think its OK; it gets developers genuinely excited to try new technology. Its only when this hype influences dangerous decisions that I'm worried about.
hhsnopek 10y ago
Not to seem naive but I work with a lot with microservices and I've never heard of lightstep... ... follow up, what's everyones opinion on this?
- kornish 10y ago
  Ben Sigelman, one of the founders, is a former Googler who's got tons of domain knowledge about profiling distributed systems of services and about how to structure calls and dependencies within those systems. He gave a fun talk at the SF Golang meetup in 2014. I, personally, am very excited to see what he's up to and will be keeping an eye out for more Lightstep stuff - I guess it's his newest thing. (if you're reading this, hi Ben! Sorry we never got together last year)
- abraae 10y ago
  One of the best recruiting/employment branding pieces I've seen. Genius!
mdgrech23 10y ago
The title is link bait and does reflect the arguments put fourth by the author.
- romanovcode 10y ago
  Not to mention it's a plug to the product he's selling.
vegabook 10y ago
nitpick: nice graph on the "information superhighway" but a label about exactly what is being measured (0.000055%, of what) would be great. Is this a word count? Or its rate of change? There's a reason our (stuffy) professors/sub-editors always insist on sources and accurate labeling. I'm only interested because the most recent data points, despite large decline, still suggest a non-negligible use of a term which I haven't heard in years other than in a small amount of anecdotes/jokes.
- djspoons 10y ago
  It's just % of bigrams that appear in Google's sample of books. [1] Not especially meaningful, I admit! [1] https://books.google.com/ngrams/info https://books.google.com/ngrams/info
iamleppert 10y ago
I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolith"), that is composed of many different libraries that have well defined interfaces which can be tested in isolation. In fact, that's how most non-web software is still written and done. The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase and enforce their control via separate repo's, and when speaking runtime, via authentication: Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance of her service that gives a guess at how long the car has to arrive to pick poor end user Bob up. I've seen this same thing play out countless times at large tech companies and startups alike. It has nothing to do with building scalable, or more maintainable, or more cleverly designed applications. If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. Not to mention all the issues and headaches caused by fan out of tons of API requests, complicated caching scenarios, etc. I've seen the horror of microservices architecture where no one person is responsible for the actual app, only their "service". There are a few exceptions where its useful to scale out parts of a distributed application, but in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control.
- solipsism 10y ago
  in 99% of my experience the services aren't a real distributed system anyway What is a real distributed system?
  - lifeisstillgood 10y ago
    To work that out you need to go back when the Galaxy was young, men were real men, women were real women, and small brown furry distributed systems from Alpha Centauri were real small brown furry distributed systems from Alpha Centauri.... Sorry...
lobster_johnson 10y ago
I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability. I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have login, storage, analytics, reporting, logging, data integrations, various forms of messaging, business-structural stuff, etc. etc. all bundled up as separate services. The front ends just use these services to build a coherent product. The front end is the monolith: The microservices are the cloud. For example, let's say I wanted to create a new product called "Hacker News". I'd use our storage service to store links and comments. I'd use the login service to let users log in. I'd use our messaging service to send notifications about things like verifying your email or send password resets. I'd use our analytics backend to emit events for reporting. And so on. I could easily build the whole thing without writing a single line of backend code, and without setting up a new cluster, because every backend service has been designed with multitenancy from the start. This ability to piggyback on a platform of services where I think the real utility of microservices lies. Everything else — fine-grained scalability, smaller surface for tests, language-independence, swappable implementations, etc. etc. — are secondary to that.
- deleted 10y ago
  [deleted]
- carterehsmith 10y ago
  You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?
  - fleitz 10y ago
    It's especially fun when you get to write the monolith 3 times over for web, ios and android.
    - carterehsmith 10y ago
tomc1985 10y ago
It is weird to read people write about microservices (or some other tech fad) as if it is this otherworldly thing that requires instruction and training. So many words dedicated to describing the supposedly bad old days! All this stuff is just another aspect in the life of a practitioner of computing. A proper expert should see these things not as a fad, but as a collection of techniques that can be added or subtracted to at will depending on the prevailing need. It's silly to declare any of these fads dead or alive, they're just simply techniques that ...people... have bundled together under a common label
- collyw 10y ago
  I think after a certain amount of years you start realizing every new fad is just a rehash of some old ideas. (You ought to notice this as you get more experienced).
- xxs 10y ago
  ...but you can write (and sell) books about, talk at conferences too
  - tomc1985 10y ago
    Ah yes, the great circlejerk
rbosinger 10y ago
Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.
rbosinger 10y ago
Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.
andyidsinga 10y ago
re: "it was never the size of the services that mattered: it was the connections and the relationships between them" re relationships I would say these are better thought of through the lens of separation of concerns. imo, connections, a la protocols like http will fade into the background and be a focus of ops. A piece of code knows to write/read data to/from _________, for which it has been authorized access by address/hashname/entity.
ianamartin 10y ago
I'm not totally convinced that allowing developers to build faster is really all that great of an idea. At least not the sacred ideal that seems to be accepted without any question. Most of what I see when people are moving fast is building things as fast as they can think of them based on the first idea that comes to mind that sounds like it might get things done. But the reality is that the first way that you think of implementing something isn't always the best. It's often just about the worst. Giving people the ability to take any whim of a design and run with it all the way to production isn't the best thing overall for software quality. Perhaps I'm alone here, but I'd like for developers to slow down and put some thought into what they are building, and how it's supposed to work, and if it's going to be able to do what it needs to do. I see a lot of "close enough" in my line of work. I know it's different in a startup, where testing the idea now is important, and I'm not slamming that. But the vast majority of developers don't work in startups where getting a product to market before a competitor is the difference between making billions and going home broke. We temper our desire for perfection by reminding ourselves that good enough is okay for now. I'd like us to temper our desire for speed by remembering that there is such a thing as soon enough.
- nkassis 10y ago
  What you are describing is definitively an issue I face every day but I don't think speed of development is the issue. Higher productivity is good but often what is called higher productivity is just due to carelessly ignoring design and planning in favor of get things done now mentality. Often the worse offenders are rewarded for being highly productive and the people who end up having to cleanup, refactor and get things actually working are not acknowledge for the vital effort they put in. In my view this is the result of bad management incentives and failure to properly asses results and contributions.
danblick 10y ago
I'm sorry -- I think the author completely misses the point about why microservices were controversial at all? Distributed systems are not the same as centralized ones, and you cannot paper over the differences between the two. It is wrong to think that distributed microservices will completely replace centralized services in some future paradise. The difference is not a tech fad; it's more like a law of nature. Distributed systems should plan for network failures, yet nobody wants to get a "503" from their CPU.
- AstralStorm 10y ago
  You will get 503 from your kernel if you try hard enough. Handling this is technically required in any application, but often ignored, especially when allocating memory. (Because there out is a deferred failure.)
TickleSteve 10y ago
"Microservices" are a new name for a very old concept. This is just low-coupling, high-cohesion by another name. Small, composable, decoupled, highly cohesive components are what "good" software has been about for decades, but it now has a new name in the server s/w world; "Microservices". Only the name is new & hyped. The concepts have been true forever.
- alayne 10y ago
  There is software and concepts around managing microservices that didn't exist before, and so on. Nothing can be new when you use such a vague way of comparing things. There were electric cars in the 1800s, why talk about Tesla?
  - TickleSteve 10y ago
    ...so what is a new concept regarding microservices? I don't see anything new... new tools, granted. Then again, there's new tools being produced every day for every architectural style.
kevinr 10y ago
I feel like maybe the Big Idea of microservices is that web APIs provide better isolation guarantees than library calls, and now with the move to SaaS either the scale of our applications is large enough or (more likely) with virtualization the intra-server network latency is small enough that we can afford the extra overhead of web APIs relative to library calls in exchange for that isolation.
k__ 10y ago
I had the feeling that microservices would add too much of complexity, but with FaaS this is canceled out by the fact that almost all server management complexity is handled by a different company.
drdaeman 10y ago
I don't know about the microservices and stuff, but I've got one cumbersome monolith to deal with, and it had started to rot (you know, rely on outdated dependencies that one can't upgrade without significant effort etc etc). Splitting it to a few isolated different systems looked like the only sane choice. Luckily, I've had to redo one logical part of the monolith anyway, because of some changing business requirements. So I made it a separate independent project, that had used all the modern currently-stable tech (rather than few-years-old one + accumulated baggage of the past architectural mistakes) and it all went quite nicely. It took me 1.5 weeks (quite busy ones, but meh) to extract all the old code pieces that I've needed, clean them up, update with the new logic, and get the freshly-minted project ready, tested, packaged up and running in production. The only thing I've lost is ability to run cross-db queries (we just have a folder of read-only SQL query snippets to fetch some useful statistics once a week or so), because I put the data in a separate database. I hope, postgres_fdw would work when I'll need it. Would I've tried to update the whole monolith, it would've taken me months. So, the next time I'll work on some large-enough part, I'll probably extract it into a fresh project as well. As I see it, I'll end up with a remains of legacy project surrounded by a few small(er) monoliths. And then the legacy piece would be small enough to get cleaned up. (I don't know about micro- scale and putting every tiny thing into a different microservice, though. I have an impression it requires a lot of extra unwanted cognitive load to manage so seems like an overkill to me.) So, my point is: software (code) rots over time. Multiple projects (services) allow to update pieces at different pace, which is less stressful on developers.
ris 10y ago
Another good article on this subject: https://m.signalvnoise.com/the-majestic-monolith-29166d022228 https://m.signalvnoise.com/the-majestic-monolith-29166d02222... My experience with microservices has been pretty painful. My analogy of microservices is it's a bit like building a car factory on two sides of the Danube. And there's no phone line in between. You've got a factory building cars up to a certain point, but then they have to stop work and pack it all up onto a barge, figure out how to fit everything on the barge and send it away across the river for the other side to spend time unpacking & figure out how it all fits together... As a django guy, I've tended to follow the pattern of spending time making my models nice and rich, with useful traits which will be helpful at all levels of the app down to the views. To then have to pack this all up and deliver some "dumb" json to the other side feels like a massive waste of time. With microservices I spend my life marshalling data around. And the number of times I've realized I've just spent an hour discussing the philosophical implications of how a particular bit of the rest interface should be designed, all for an interface that we're the only consumers of and doesn't need to exist in the first place... I've found depressing. The ramifications on testing are a further story. Do you have to test all kinds of ways you can receive your rest requests malformed if you're the only consumer and know exactly how you're going to use it? Good use of developer time?
gedrap 10y ago
When it comes to services, I think it's worth to talk about one common use case which comes with different motivations and problems: adding new features to old, probably poorly engineered, monolithic application. Features that are not tiny yet-another-crud-on-a-new-table but completely different than most of the existing functionality. In this case, they really pay off if they are separated well which sometimes is hard. But executed well, it allows to keep moving quickly as the requirements grow. Of course, this is not an excuse to avoid refactoring monolithic application, improving testing, etc. I've worked in such a setting in companies, and both times it was a win and helped to build important to the business features really quickly and reliably. But is it worth to write an application from scratch in a service oriented architecture? Probably not, most of the time. Especially if 'product to market time', 'MVP' and similar concepts are very important for you.
justinhj 10y ago
I joined a company where the proof of concept had, inevitably, become the monolithic application we would work on for the next two years. Everyone on the team agreed that the monolith would be a liability so we started to share knowledge on microservices and plan for that in the future. To do this we stuck to a handful of rules. Systems should do one thing and do it well, with a well defined api and protocol. Whilst all the data may be in the same redis and MySQL instance we made the data store configurable as well its location, and made sure systems did not read or write each other's data. We wrote generic systems as libraries with no dependencies on the rest of the monolith. The results of this work, which was a lot of refactoring, is that when we decided to farm some work out to a contractor we could do so as a microservice. They worked in their favourite language with their own tools, implementing the api we wanted over a specified protocol. At any point it would be possible to split out services to scale them horizontally, but we didn't have to until we need to, because every split increases the operational costs and complexities a little.
daxfohl 10y ago
Every generation's microlith is the next generation's monolith. For this generation, the end of microservices will be when we can look at a cluster as one big unit, and deploy a microlithic monolith on it. For the next generation, who knows how they will slice it up.
orasis 10y ago
The Gartner Hype Cycle appears to be accelerating...

258 points by reimertz 10y ago

EGreg 10y ago

John Titor is back!!

stephengillie 10y ago
Did he bring back the IBM 5100 that he promised? https://en.wikipedia.org/wiki/John_Titor https://en.wikipedia.org/wiki/John_Titor

msoad 10y ago

One thing I don't like about SOA is that an error does not have a full stack trace. I know Zipkin exists but it's nowhere close to what we had in a monolithic app where you could just put a breakpoint and trace back to where exactly an error is thrown. If we can find a way of running a giant monolithic app in development and production environment without vertically scaling our machines, I would rather have that. Every bug I'm working on is like a mystery that I have to hop to many services to find what's going. I also think HTTP is the worst protocol for apps to talk to each other.

malandrew 10y ago
http://opentracing.io/ http://opentracing.io/
- slowmovintarget 10y ago
  I was thinking of a simpler "Y U no log?!?" with correlation IDs but this is much cooler.
themihai 10y ago
Depending on your requirements micro-services may be a good or a bad solution. If the communication/protocol becomes too chatty that may be a sign you are doing it wrong.
jeremiep 10y ago
How is that different from debugging a multi-threaded or networked application? In both cases barely entering the debugger changes the behavior of the system. Heck even an asynchronous program running on a single thread doesn't have full stack traces. Having worked with both monolithic and SOA apps, the later yields radically simpler architectures and from there you spend a lot less time debugging. The older I grow as a programmer, the more I dislike monoliths. I'd rather have simpler programs where entire classes of bugs are guaranteed never to happen. I have yet to see a single monolithic app without serious technical and conceptual debt. The worst thing is that back when I thought monoliths were great I had absolutely no idea things could be so much simpler. Also, HTTP/1.1 is a fantastic protocol. Its dead-simple to implement, debug, cache, send through proxies who won't understand your custom headers or body format and whatnot. It even gives you an extra layer of routing on top of TCP/IP! This is exactly what you want to build systems with.
uluyol 10y ago
What's wrong with HTTP? If you're going to build an RPC protocol, you are going to need encryption, stream multiplexing, a way to distinguish RPC methods, support for extensions (e.g. auth), and compression. Add the fact that high performance HTTP servers and clients exist in most languages, and building an RPC protocol on top of HTTP sounds pretty attractive. No wonder gRPC did exactly that.
- devonkim 10y ago
  Tons of round trip calls potentially in most RPC-style systems are one start, which Cap'n Proto addresses with its unique style of avoiding round-trips for many network transactions which can drastically reduce network chatter. Security is addressed simultaneously (but not necessarily sufficiently for many people or regulatory bodies) in Cap'n Proto at least via use of capabilities instead of building it into transport layers.
RhodesianHunter 10y ago
Any service taking requests from a client generates a UUID and passes it through to any additional services it calls. Most microservice frameworks have this functionality built in. You log to a central store such as an ELK stack or any of the great third party offerings. When you need to see the entire stack trace you search by the id.
djspoons 10y ago
Tracing and debugging-in-developer are solving different problems, though: tracing is there to help you understand issues that you can't reproduce in development. And for the record, Zipkin is only one tracing tool and is really aimed at helping you address latency issues, not errors.

sinzone 10y ago

When this year I came back from Dockercon I immediately wanted to write something very similar to what this article describes. I wanted to imagine a world where Containers and Microservices were part of the past already, and so I wrote "DockerCon 2020" [1] and how it will look like. [1] https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz3pruf4 https://medium.com/@sinzone/dockercon-2020-a513ed04eefb#.rbz...

stevehiehn 10y ago

Maybe a more appropriate title could be 'Microservices are the Norm'

brianwawok 10y ago
I don't think they are. I would be surprised if 10% of new code right now was coded in microservices.
- stevehiehn 10y ago
  Ya, you're probably right. Its likely just my bias. It feels like its the only thing i encounter at my day job.
spriggan3 10y ago
In S.F. startups maybe, not in the enterprise world. Enterprise is barely SOA today, they aren't going to throw 10/20 y.o. apps that still work for the latest fad. Just like MongoDB didn't replace Oracle or SQLServer just because it was hip.
- brightball 10y ago
  The enterprise world I lived in was all SOA 10 years ago. WSDL services everywhere.

tuananh 10y ago

They have the word "microservice" on their homepage :D

dasil003 10y ago

Equating "Microservices" with "Information Superhighway" really shows the tech bubble that this article is written in. "Information Superhighway" was a vacuous but mainstream term used by politicians and public figures. "Microservices" is a tech hype train led by expensive consultants and pickaxe companies thriving off the current tech boom. Don't get me wrong, a service-oriented architecture is the only thing that scales to large companies. Once you get to dozens of engineers and millions of lines of code you will inevitably need to have an SOA because Conway's law. Also, there is a learning curve to building microservices which improved tooling really helps with. However the thing that really grates at me is how these articles say things like: > Services are now an everyday, every-developer way of thinking With nary a mention of the overhead. There is no way around it, distributed systems have an irreducible complexity no matter how good your tooling and boilerplate is. You have to put in extra work to decouple everything and handle failure in a way that actually reap the benefits of the distributed system. And in the end, what these articles always gloss over is the interface between these systems. If you can easily define an interface between systems that stays relatively stable as the service evolves, then congratulations, you have a good candidate for a service with minimal overhead. But for most applications, those interfaces are shifting all the time, and there is no better tooling than multiple logical services running within one binary and build system where integration testing and validation is cheap. This is a real fucking problem people, it's not going to go away because there's a couple billion dollars worth of venture-backed startups ready to blow their cash on you in the vain and most likely misplaced hope that they are actually going to have to scale to dozens of engineers. Premature scalability is one of the worst siren songs for young engineers and we're seeing it in spades right now.

pm90 10y ago
This is a great point. I don't think the hype is due to a fad alone. There are a lot of good reason why microservices are much easier to create and deploy today: containerization and the associated technology around it. This makes microservices a very natural paradigm for app deployment. Of course, its not a holy grail. But we see that kind of thing over and over again. I think its OK; it gets developers genuinely excited to try new technology. Its only when this hype influences dangerous decisions that I'm worried about.

hhsnopek 10y ago

Not to seem naive but I work with a lot with microservices and I've never heard of lightstep... ... follow up, what's everyones opinion on this?

kornish 10y ago
Ben Sigelman, one of the founders, is a former Googler who's got tons of domain knowledge about profiling distributed systems of services and about how to structure calls and dependencies within those systems. He gave a fun talk at the SF Golang meetup in 2014. I, personally, am very excited to see what he's up to and will be keeping an eye out for more Lightstep stuff - I guess it's his newest thing. (if you're reading this, hi Ben! Sorry we never got together last year)
abraae 10y ago
One of the best recruiting/employment branding pieces I've seen. Genius!

mdgrech23 10y ago

The title is link bait and does reflect the arguments put fourth by the author.

romanovcode 10y ago
Not to mention it's a plug to the product he's selling.

vegabook 10y ago

nitpick: nice graph on the "information superhighway" but a label about exactly what is being measured (0.000055%, of what) would be great. Is this a word count? Or its rate of change? There's a reason our (stuffy) professors/sub-editors always insist on sources and accurate labeling. I'm only interested because the most recent data points, despite large decline, still suggest a non-negligible use of a term which I haven't heard in years other than in a small amount of anecdotes/jokes.

djspoons 10y ago
It's just % of bigrams that appear in Google's sample of books. [1] Not especially meaningful, I admit! [1] https://books.google.com/ngrams/info https://books.google.com/ngrams/info

iamleppert 10y ago

I'll tell you the real reason behind microservices: developer fiefdoms. "Faux-Specialization". It allows developers to feel like they have control over certain pieces of infrastructure and run the gambit on their strategy for getting ever more increasing pieces of the pie. It has nothing to do with building reliable software. You could just as easily build and deploy a single networked application (so called "monolith"), that is composed of many different libraries that have well defined interfaces which can be tested in isolation. In fact, that's how most non-web software is still written and done. The real reason is that by having these microservices, it allows single developers or teams to own or control parts of the codebase and enforce their control via separate repo's, and when speaking runtime, via authentication: Sally can't see the code to Joe's service and Joe can't make requests to Sally's production instance of her service that gives a guess at how long the car has to arrive to pick poor end user Bob up. I've seen this same thing play out countless times at large tech companies and startups alike. It has nothing to do with building scalable, or more maintainable, or more cleverly designed applications. If anything, it adds more complexity because now we need to do all kinds of data marshaling, error checking, monitoring, have more infrastructure for something that should have been done in shared memory/in-process to begin with. Not to mention all the issues and headaches caused by fan out of tons of API requests, complicated caching scenarios, etc. I've seen the horror of microservices architecture where no one person is responsible for the actual app, only their "service". There are a few exceptions where its useful to scale out parts of a distributed application, but in 99% of my experience the services aren't a real distributed system anyway and are vaguely organized by function, developer interest, and yes, control.

solipsism 10y ago
in 99% of my experience the services aren't a real distributed system anyway What is a real distributed system?
- lifeisstillgood 10y ago
  To work that out you need to go back when the Galaxy was young, men were real men, women were real women, and small brown furry distributed systems from Alpha Centauri were real small brown furry distributed systems from Alpha Centauri.... Sorry...

lobster_johnson 10y ago

I see several people criticize microservices here. We've been doing it for about 6 years and are extremely happy with it. A core principle which a lot of people and articles ignore, though, is reusability. I bring this up on HN every time there's a discussion about microservices, yet I've never seen any discussion about it. Essentially, you build out the backend to act as a library for your front end. So we have login, storage, analytics, reporting, logging, data integrations, various forms of messaging, business-structural stuff, etc. etc. all bundled up as separate services. The front ends just use these services to build a coherent product. The front end is the monolith: The microservices are the cloud. For example, let's say I wanted to create a new product called "Hacker News". I'd use our storage service to store links and comments. I'd use the login service to let users log in. I'd use our messaging service to send notifications about things like verifying your email or send password resets. I'd use our analytics backend to emit events for reporting. And so on. I could easily build the whole thing without writing a single line of backend code, and without setting up a new cluster, because every backend service has been designed with multitenancy from the start. This ability to piggyback on a platform of services where I think the real utility of microservices lies. Everything else — fine-grained scalability, smaller surface for tests, language-independence, swappable implementations, etc. etc. — are secondary to that.

deleted 10y ago
[deleted]
carterehsmith 10y ago
You are not getting more reusability from a bunch of microservices, compared to one big service, I don't see where you got that?
- fleitz 10y ago
  It's especially fun when you get to write the monolith 3 times over for web, ios and android.
  - carterehsmith 10y ago

tomc1985 10y ago

It is weird to read people write about microservices (or some other tech fad) as if it is this otherworldly thing that requires instruction and training. So many words dedicated to describing the supposedly bad old days! All this stuff is just another aspect in the life of a practitioner of computing. A proper expert should see these things not as a fad, but as a collection of techniques that can be added or subtracted to at will depending on the prevailing need. It's silly to declare any of these fads dead or alive, they're just simply techniques that ...people... have bundled together under a common label

collyw 10y ago
I think after a certain amount of years you start realizing every new fad is just a rehash of some old ideas. (You ought to notice this as you get more experienced).
xxs 10y ago
...but you can write (and sell) books about, talk at conferences too
- tomc1985 10y ago
  Ah yes, the great circlejerk

rbosinger 10y ago

Ok. I'll be the guy to bring up the Elixir/Erlang ideology that has gained such popularity here. Although I don't have a ton of experience with it yet it seems like the possibility of having the idea of "services" built into the language/framework design is very realistic. That's exciting for me. Although true SOA can be a mix of many technologies I personally find that scary. What happens when your whole platform ends up as a web of services on different technologies and you lose various talent? Now you have to recruit all kinds of different expertise or hope that certain services keep ticking without that knowledge in house.

rbosinger 10y ago

andyidsinga 10y ago

re: "it was never the size of the services that mattered: it was the connections and the relationships between them" re relationships I would say these are better thought of through the lens of separation of concerns. imo, connections, a la protocols like http will fade into the background and be a focus of ops. A piece of code knows to write/read data to/from _________, for which it has been authorized access by address/hashname/entity.

ianamartin 10y ago

I'm not totally convinced that allowing developers to build faster is really all that great of an idea. At least not the sacred ideal that seems to be accepted without any question. Most of what I see when people are moving fast is building things as fast as they can think of them based on the first idea that comes to mind that sounds like it might get things done. But the reality is that the first way that you think of implementing something isn't always the best. It's often just about the worst. Giving people the ability to take any whim of a design and run with it all the way to production isn't the best thing overall for software quality. Perhaps I'm alone here, but I'd like for developers to slow down and put some thought into what they are building, and how it's supposed to work, and if it's going to be able to do what it needs to do. I see a lot of "close enough" in my line of work. I know it's different in a startup, where testing the idea now is important, and I'm not slamming that. But the vast majority of developers don't work in startups where getting a product to market before a competitor is the difference between making billions and going home broke. We temper our desire for perfection by reminding ourselves that good enough is okay for now. I'd like us to temper our desire for speed by remembering that there is such a thing as soon enough.

nkassis 10y ago
What you are describing is definitively an issue I face every day but I don't think speed of development is the issue. Higher productivity is good but often what is called higher productivity is just due to carelessly ignoring design and planning in favor of get things done now mentality. Often the worse offenders are rewarded for being highly productive and the people who end up having to cleanup, refactor and get things actually working are not acknowledge for the vital effort they put in. In my view this is the result of bad management incentives and failure to properly asses results and contributions.

danblick 10y ago

I'm sorry -- I think the author completely misses the point about why microservices were controversial at all? Distributed systems are not the same as centralized ones, and you cannot paper over the differences between the two. It is wrong to think that distributed microservices will completely replace centralized services in some future paradise. The difference is not a tech fad; it's more like a law of nature. Distributed systems should plan for network failures, yet nobody wants to get a "503" from their CPU.

AstralStorm 10y ago
You will get 503 from your kernel if you try hard enough. Handling this is technically required in any application, but often ignored, especially when allocating memory. (Because there out is a deferred failure.)

TickleSteve 10y ago

"Microservices" are a new name for a very old concept. This is just low-coupling, high-cohesion by another name. Small, composable, decoupled, highly cohesive components are what "good" software has been about for decades, but it now has a new name in the server s/w world; "Microservices". Only the name is new & hyped. The concepts have been true forever.

alayne 10y ago
There is software and concepts around managing microservices that didn't exist before, and so on. Nothing can be new when you use such a vague way of comparing things. There were electric cars in the 1800s, why talk about Tesla?
- TickleSteve 10y ago
  ...so what is a new concept regarding microservices? I don't see anything new... new tools, granted. Then again, there's new tools being produced every day for every architectural style.

kevinr 10y ago

I feel like maybe the Big Idea of microservices is that web APIs provide better isolation guarantees than library calls, and now with the move to SaaS either the scale of our applications is large enough or (more likely) with virtualization the intra-server network latency is small enough that we can afford the extra overhead of web APIs relative to library calls in exchange for that isolation.

k__ 10y ago

I had the feeling that microservices would add too much of complexity, but with FaaS this is canceled out by the fact that almost all server management complexity is handled by a different company.

drdaeman 10y ago

I don't know about the microservices and stuff, but I've got one cumbersome monolith to deal with, and it had started to rot (you know, rely on outdated dependencies that one can't upgrade without significant effort etc etc). Splitting it to a few isolated different systems looked like the only sane choice. Luckily, I've had to redo one logical part of the monolith anyway, because of some changing business requirements. So I made it a separate independent project, that had used all the modern currently-stable tech (rather than few-years-old one + accumulated baggage of the past architectural mistakes) and it all went quite nicely. It took me 1.5 weeks (quite busy ones, but meh) to extract all the old code pieces that I've needed, clean them up, update with the new logic, and get the freshly-minted project ready, tested, packaged up and running in production. The only thing I've lost is ability to run cross-db queries (we just have a folder of read-only SQL query snippets to fetch some useful statistics once a week or so), because I put the data in a separate database. I hope, postgres_fdw would work when I'll need it. Would I've tried to update the whole monolith, it would've taken me months. So, the next time I'll work on some large-enough part, I'll probably extract it into a fresh project as well. As I see it, I'll end up with a remains of legacy project surrounded by a few small(er) monoliths. And then the legacy piece would be small enough to get cleaned up. (I don't know about micro- scale and putting every tiny thing into a different microservice, though. I have an impression it requires a lot of extra unwanted cognitive load to manage so seems like an overkill to me.) So, my point is: software (code) rots over time. Multiple projects (services) allow to update pieces at different pace, which is less stressful on developers.

ris 10y ago

Another good article on this subject: https://m.signalvnoise.com/the-majestic-monolith-29166d022228 https://m.signalvnoise.com/the-majestic-monolith-29166d02222... My experience with microservices has been pretty painful. My analogy of microservices is it's a bit like building a car factory on two sides of the Danube. And there's no phone line in between. You've got a factory building cars up to a certain point, but then they have to stop work and pack it all up onto a barge, figure out how to fit everything on the barge and send it away across the river for the other side to spend time unpacking & figure out how it all fits together... As a django guy, I've tended to follow the pattern of spending time making my models nice and rich, with useful traits which will be helpful at all levels of the app down to the views. To then have to pack this all up and deliver some "dumb" json to the other side feels like a massive waste of time. With microservices I spend my life marshalling data around. And the number of times I've realized I've just spent an hour discussing the philosophical implications of how a particular bit of the rest interface should be designed, all for an interface that we're the only consumers of and doesn't need to exist in the first place... I've found depressing. The ramifications on testing are a further story. Do you have to test all kinds of ways you can receive your rest requests malformed if you're the only consumer and know exactly how you're going to use it? Good use of developer time?

gedrap 10y ago

When it comes to services, I think it's worth to talk about one common use case which comes with different motivations and problems: adding new features to old, probably poorly engineered, monolithic application. Features that are not tiny yet-another-crud-on-a-new-table but completely different than most of the existing functionality. In this case, they really pay off if they are separated well which sometimes is hard. But executed well, it allows to keep moving quickly as the requirements grow. Of course, this is not an excuse to avoid refactoring monolithic application, improving testing, etc. I've worked in such a setting in companies, and both times it was a win and helped to build important to the business features really quickly and reliably. But is it worth to write an application from scratch in a service oriented architecture? Probably not, most of the time. Especially if 'product to market time', 'MVP' and similar concepts are very important for you.

justinhj 10y ago

I joined a company where the proof of concept had, inevitably, become the monolithic application we would work on for the next two years. Everyone on the team agreed that the monolith would be a liability so we started to share knowledge on microservices and plan for that in the future. To do this we stuck to a handful of rules. Systems should do one thing and do it well, with a well defined api and protocol. Whilst all the data may be in the same redis and MySQL instance we made the data store configurable as well its location, and made sure systems did not read or write each other's data. We wrote generic systems as libraries with no dependencies on the rest of the monolith. The results of this work, which was a lot of refactoring, is that when we decided to farm some work out to a contractor we could do so as a microservice. They worked in their favourite language with their own tools, implementing the api we wanted over a specified protocol. At any point it would be possible to split out services to scale them horizontally, but we didn't have to until we need to, because every split increases the operational costs and complexities a little.

daxfohl 10y ago

Every generation's microlith is the next generation's monolith. For this generation, the end of microservices will be when we can look at a cluster as one big unit, and deploy a microlithic monolith on it. For the next generation, who knows how they will slice it up.

orasis 10y ago

The Gartner Hype Cycle appears to be accelerating...