I have been doing microservices for 4 years now and I can tell you something: do not go there. The tools are simply not there.
Although I am working on one platform like that right now (see https://github.com/1backend/1backend) the reason I started it was more the fact that I could not easily deploy a custom tiny service and call it easily.
We have solved both problem with 1Backend: launching a new service is as easy as creating a git repo on GitHub, and calling them is just like calling a library with the autogenerated clients.
That being said, until a project like 1Backend matures, anyone who starts their startup on a microservices architecture instead of a simple monolitic one is out of their skull.*
I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen.
Don't be that startup! We managed to screw it up with 100+ million dollars in funding, which was (is) extremely exceptional in Europe. Of course the tech was only part of the reason for failure, still: there are better way of spending money than chasing bugs across hundreds of services and building instrumentation.
*Edit: this sentence of mine was very unfortunately worded and said the exact opposite of what I meant. Hopefully the tons of upvotes I got was because that the upvoters correctly inferred from the context that I advice you to start with a monolith, and not with microservices. Thanks.
> I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen.
Yeah, but didn't Uber do it because they were going for a huge headcount increase? They went from 50 engineers to 2000 in a year or so and they were facing all sorts of non tech issues such as shipping the org chart, engineer recruiting limitations (i.e. easier to recruit 2000 devs knowing any language than just 2000 Java devs), etc.
I don't think you can apply the lessons from a startup burning billions per year in many other places...
- if you need to scale the number of teams working on the same product you need to introduce microservices to make the teams work independently from each other.
- if you need to scale the (monolith) service and it is too expensive to just scale it n times. microservices can help because you can scale each microservice independently.
- that's said the overhead is real. There have been quite a few publications and advocates (like Randy Shoup) that staying monolith is fine until you have pain that a microservice architecture can ease.
All those reasons are very fine ones - but it's still a dangerous move to go microservice style. You have to know what you are doing, and in our buzzword driven industry that's not the case usually.
Little insidious time wasters will creep into your work flow and they will lurk there eat away dollars and you won't even notice.
I constantly switch back and forth between working on monolithic and microservice apps and for the majority of companies sticking to a monolith until the pain points you mentioned become unbearable is the good call.
Even then, just break down your apps to bigger sized services, and stop when the pain goes away. Microservices is a catchy name but if anything micro is the poison there.
Given that I have been part of a team that independently invented micro-services, and that since knowing that, I’ve met several other people who have done similarly, it can’t imagine that it’s all that hard. To me, it was just a natural evolution.
What do you consider as the most important things that people are do wrong?
Also, could you enumerate the time-wasters? Off hand, besides occasionally having to re-consolidate the architecture, I can’t think of many. It would be good to know how much the time-wasters cost in contrast to the alternatives.
> if you need to scale the number of teams working on the same product
You can do that by several different ways. Overall, if one wants a "one size fits all" answer to how to break code into teams, it is by breaking the code into libraries, not services. Services are a niche tech here, to be considered when the others won't suffice.
> if you need to scale the (monolith) service and it is too expensive to just scale it n times.
Again, nearly every time this happens, the correct answer is to refactor the monolith so replicating it scales. Services are only for those cases where this won't suffice.
I don't think I disagree with how you think. But I do think your comment is easily misunderstood and harmful without those qualifiers.
I’ve seen the library approach in practice. It is works to a certain point, but it isn’t too long until having a single deployable[1] artifact becomes as much of a bottleneck as having a single codebase, if not more. Taking this approach makes it harder to do other things that are just as important, such as continuous delivery, empowering development teams to take ownership of operational excellence, or even ship updates in a reliable and timely fashion.
Most of the hatred towards microservices is probably better directed at REST, which is a good paradigm for serving documents to web browsers but is overcomplicated for microservices. RPC is a good alternative, and gRPC is a good implementation of it.
[1] My phone autocorrected this to “deplorable”, which is also a good adjective for a monolithic web application that contains lots of libraries and is only deployable as one artifact.
To my siblings: you don't know how libraries work.
If you understand binary compatibility you can deploy a library without deploying its client applications/libraries (they would need to be restarted, however).
In fact, this is one of the very reasons people invented shared libraries! It's why, for example, Linux distros are based on shared libraries: one can update large swaths of the system by updating a single package.
If your languages don't support this then it would be very unfortunate indeed.
Yeah, I've not seen much in the way of definitions about what the bounds of a "micro" service are or how much scope each one includes.
It sounds like you're saying that a single micro service maps to a team. Do you think each team should manage many micro services and how many do you think each team should manage?
I'm generally interested but having been the guy on dev teams to handle most of the configuration management stuff I've not really been willing to listen to micro service advocates.
Depending on runtime environments/architectures the CM costs sound prohibitive at best.
One per team sounds about right, unless there are some components that don't fit together in the same runtime (e.g. a data lookup with a little business logic might not fit with a module sending out emails). That said libraries go a long way to reduce the dependency graph and prevent developers from creating unnecessary edges by randomly autocompleting code.
IME we had multiple services for each team. But we were in the process of carving several mutually incompatible whales into common, shared services, YMMV. So we had one team maintaining each whale, and our senior engineers would collaborate to identify pieces that could be cut from each and replaced with a common service. If the innards of one whale matched our service better than the others, that whale's team got to write the service. Eventually all the teams would port their products to the new, resulting service.
This meant, for example, that my team, had our whale, an audio transcoding service, an automated transcription service, a post-phone-call messaging service, and several data integrations.
If you need a whole team to do nothing but maintain a service, it seems to me like you built it to do too much.
Or microservices are strongly indicated if you are in a SaaS industry as we are (HR software), where individual customers want choice over the components making up their own stack.
Yes, if the customer was happy to buy everything from a single vendor that would work perfectly fine. But as per sibling comments, that's not the way that the enterprise HR software market works. There are many, many very specialised vendors that do just one thing.
This is perhaps off-topic but why would you let your SaaS customers dictate the composition of the stack? This seems to obviate one of the major benefits for customers, namely that they don't sweat the details.
It depends on your market. If you are "SaaS for the masses" (i.e. you've got 50,000+ customers) then you're right - any customization is limited to "pick a color from our predefined palette". But if your customers are Fortune 500 -- they can and will demand special consideration.
The nature of software for managing humans is that it's very fuzzy, fashion/tend driven, diverse.
E.g a recent trend is for companies to try and reduce the number of undesirable applicants they get for jobs (since in a big e.g retailer, saying no to a candidate is likely also saying no to a customer).
So customer now needs to inject an e.g culture fit quiz into the candidate experience, which only unlocks the apply button once the candidate has "passed".
This kind of tweaking and evolvement is not possible within a monolith, so good APIs allowing vendors of the customer's choice to inject functionality are essential.
That functionality can then be injected in the form of a small app that does one thing and does it well, has it's own database, i.e has many of the characteristics of what people think of as microservices.
I don't think it's helpful to conflate "microservices" with "dynamically-loaded code". Many, many programs have a plugin system that can completely alter their behavior while having all the characteristics of a monolith - single process, function calls rather than a message bus, central control of flow rather than decentralized, etc.
Well, this can be a fruitless discussion without a shared understanding of what a microservice is.
To Martin Fowler:
> In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
Assembling HR ecosystems from separate apps certainly meets all of the points above.
Ah, this is more what I might call 'macroservices' - API-centric full applications which can be used standalone with their own client interfaces or API-assembled into bigger solutions. I think this should be the default architectural approach and was what Yegge wrote about Bezos mandating at Amazon.
From what I'm seeing, the microservices style is commonly being used for much smaller services a la Unix, typically for reuse across an org. Introduces too many issues around SPOF, orchestration and queuing, versioning, discoverability. I think Lambda is the correct evolution for making that work (if nothing else let AWS figure out stuff like failover, deployment, and the standards for fabric between functions).
You talk as if the customer already has the quiz content in their mind, and just needs a few web pages to present it.
That's not the way the industry works.
Some exciting, specialised startup develops some kind of cool UI blended with some psych validated content, and manages to get it installed at a couple of large reference clients, and then finally manages to draw a link between the quiz results that candidates achieve, and their ultimate chances of successful employment (maybe just getting hired - maybe their on the job performance after X months).
The customer is buying into this package of leading edge stuff. They don't want their existing vendor to have some junior developer hack something up and put it behind a feature flag. They want the new shiny stuff, and they want it from the new shiny vendor.
We did that without microservices, just dynamically-loaded modules on a monolith base. A custom configuration for each client selected which modules to load at runtime.
Typically in the enterprise HR software space, the customer does not want to buy all their components from a single vendor. If they want a culture fit quiz, they do not go to their ATS (applicant tracking system) vendor for it. They go to an organization that has specific skills in this particular area, and has onboard psychologist(s) who can demonstrate the validity of said quiz.
The code behind such a quiz is usually trivial - the intellectual property not so much.
Thanks for being so candid. I made the same mistake at my startup when given the chance to start greenfield due to a pivot. I ate my pride and switched back to a monolith after realizing I was spending more time doing devops than I was coding.
predictable repeatable and maintainable are all great and important things. But micro services makes everything you do less predictable repeatable and maintainable. You must automate many more things with micro services to achieve the same level of predictable repeatable and maintainable as you have with a monolith.
There are many possible benefits of microservices, few of which outweigh the massive costs for many (dare I say most) startups.
I agree. Microservices have no tooling and a shitload of overhead. After working on such a project I think microservices are an anti-pattern. After a certain point you have to maintain state across service boundaries and all hell breaks loose.
By spitting up your application you basically throw away everything a database gives you as far as ordering and atomicity. And you end up building a giant distributed database yourself.
Stay away from microservices. I've seen people try to make it work multiple times, the overhead for failure scenarios, lack of distributed transactions, and eventual consistency multiply the size of the codebase
Most buzzword chasers end up implementing a distributed monolith.
Services work well when you have one or two services per team, the problem space is divided in the right places and the teams provide a service to each others, not code.
When you see more services than developers it's often a bad sign.
...with one caveat: How long has the system been in place?
We have services that were built and are in the background because they are effectively finished (for now.)
An example would be a service that handles a third party integration. It might get a commit a month once it's built.
From my limited perspective, I look at two warning signs: Do changes require changes to more than two services on a regular basis? Ideally, the majority of changes are limited to one service. If you're propagating changes up a stack, it is going to be a slow change. (The whole point of microservices is that once set up, you can move faster, right?)
Yes. IME, once a service is dialed in, it should need little maintenance. That's how my team was able to handle responsibility for 5+ services on top of our slowly carved up monolith.
If your microservice code is significantly harder to manage than your monolith, you've factored it wrong. Which means you shouldn't find yourself constantly working on 6 or 7 different services at once. If so, try a different decomposition.
Saying one team per service is like saying "a team should only handle one or two classes".
The fad of "microservices" is a disaster start-to-finish.
Don't be fooled into believing that microservices are popular based on technical merit. As the parent noted, this will just make things harder by trying to micro-ize a startup. Microservices are a thing primarily for their political convenience and dynamic, and they're just dressed up as a technical thing.
[Sideline: most of our technical fads are this way. Err on the side of "letting developers feel important and special while requiring as little effort as possible". Cloud servers are this way because it makes Unix greybeards transparent, and the brogrammer won't have to feel inadequate next to him/her, OR worry about esoteric command-line incantations. Document databases are this way for the same reasons, but replace esoteric command-line incantations with esoteric SQL aggregates (or any useful schema development at all, actually) and greybeards with DBAs. Rinse and repeat for every major development fad.]
Microservices are popular due to Conway's Law [0]. They give an out to people who would rather avoid the difficulties of interfacing, deliberating, and collaborating with other people in their organization. They don't have to decide on a common language, they don't have to decide on a common style, they don't have to do anything; they can go run amok, treating the company codebase as their personal playground, under cover of "super cool new-wavy best practices". "Google is doing it. You want to be like Google, right?"
There are potential good designs that would qualify as "microservice architectures", but I've seen them only rarely. What I see more often is what I like to call "brittle-services": dozens of tiny, fragile, interdependent units that are virtually impossible to debug, instrument, or reason about cohesively.
At $DAY_JOB, we have tons of these; if one service starts to slack off, there is a giant waterfall -- ahem -- of failures that cascades across everything else. The software has been structured this way for purely political reasons, even though no one would be willing to admit it.
Like everything else important, good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented. Unfortunately for the hoi polloi, it can't be generalized into a formula or paradigm like "use microservices", but it seems in any field, there are many posers eager to try.
I'm sorry that at your day job you deal with poorly built software, but that doesn't sound like an argument against microservices. Cascading failures are one of the first things you should have dealt with in your design (and eventually they would become a benefit since your failures have nice boundaries, and are explicit in your code).
You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers.
> good software design boils down to designers with substantial experience, good judgment, and the authority and respect to see their designs faithfully implemented.
Like this - projecting much?
Microservice architecture is a tool. It isn't a replacement for you or your job. It isn't a replacement for communication. There is a recognition that Conway's law is a serious problem in orgs as they scale - microservices (in part) attempt to deal with this.
There are many other benefits. It makes things like DDD easier, since your domains and services can be tied closely together.
It makes scaling at a finer grained level easier - a problem a lot of companies may run into as they scale from a few customers to many. I've certainly run into this problem at a company that was moving from distributed monoliths to microservices.
It has downsides - a more complicated rollout / deployment structure, less shared knowledge of services, and others.
Acting like it's only hype or just 'those darn young devs' makes you sound really silly, especially as someone who's seen Microservices both fail miserably and turn things around completely (in a positive way) for companies.
You say it comes down to experienced developers making good decisions - can you not see that Microservices are designed to help with that? The way you break apart your services, their domains, the 'bounded context', etc is all a tool to help you build things well.
>You sound extremely bitter, and extremely pompous with your "all the other devs are just dumb, I'm the only one who can see through the hype" attitude; especially your comment about younger developers.
I didn't say anything about "younger developers". Which comment are you referring to specifically?
Also, I hardly think I'm the only one who can see through the hype. Check out the rest of this thread. Most of the replies, including the parent post to which I was replying, could be characterized as anti-microservice.
Tech fads are rarely about good developers. They're normally about non-developer technical managers and/or bad developers, who are sometimes more self-aware than they appear at first glance and are consciously seeking diversions. Good inexperienced devs may be taken in by the first fad or two, but they generally come to realize that it's same shit, different day within a few years, and their skill level limits the direct damage (though their adherence to the fad may set the stage for additional indirect damage).
It was not my intent to offend or accuse anyone by criticizing this particular tech fad, and I'm sorry that you appear to have taken it personally.
---
I don't think we disagree about "microservice architecture" as a tool. Like all tools, it needs skilled practitioners to be used well. "Microservice architecture" is a bad descriptive term for a tool because it's too broad to have much specific meaning, but I accept that some people could use it to describe something decent, which I've already stated.
As my post said, however, I was discussing "microservice architecture" as a fad, which, let's be honest, is the case across the vast majority of cases in which the term "microservice architecture" is used.
People who aren't blindly chasing buzzwords are more likely to think of their architecture as a holistic entity built from a variety of useful and specific components rather than a zipped-up incarnation of a single $HOT_TREND, and are thus more likely to describe it descriptively, e.g., "we try to employ a reasonable separation of concerns", "we have a handful of independent services on the back-end", etc.
These things show a thoughtful, specific consideration of principles rather than literalist word-thought, and it's a good guideline (but, like all guidelines, imperfect!) for whether or not someone has processed what they're discussing or whether they're mindlessly mimicking the people they consider authoritative/influential.
It was not my intent to offend reasonable, thoughtful engineers who have implemented what they call "a microservice architecture". I meant only to indicate that this terminology is a red flag for a tech fad, under which many unreasonable, thoughtless "engineers" are seeking cover.
My personal recommendation would be to consider the terminology lost and not develop a new buzzword to replace it, as that will surely become lost too (see also: "SOA"/"service-oriented architecture", the previous incarnation).
You edited your original response. I was going to reply and say that HN is not a place that is safe to have an opinion that dissents from the hive mind. Unless you follow neatly along, be prepared for the blowback. ¯\_(ツ)_/¯
Yeah, I decided it wasn't worth the potential contention right now -- I have some stuff I'm trying to wrap up before I head out for some holiday festivities with the kids and I didn't want to worry about the shitstorm it may've stirred up. But I appreciate your comment; thanks for expressing it. As we know from the blurb I ended up snipping, I can vouch for that first-hand. I was just a little surprised to see it so blatantly.
I'm aware that this has all been done before to an extent, so I'm trying not to reinvent the wheel and learn from the past. Advice, critique, or encouragement is very welcome indeed.
I disagree. Companies that start with a monolith then face an exceptionally difficult task of 'moving to micro services' because they need that architecture to support team growth. This task amounts to replacing the engine of a running car.
I agree in general the tools are lacking but if you use AWS,GCP, or w/e you get a huge boost on the tooling.
You can also have structure and strong separation between different parts of the system inside a monolith.
I see the point of microservices for cases where you want to use different tech stack for one part of system or need special scalability. I don't see the point in going that route to only have separation between components or being able to split work.
If you are afraid that you won't get the monolith architecture right, you should be afraid of the same thing with microservices.
>This task amounts to replacing the engine of a running car.
I hate this phraseology, and IMO it's a telltale sign of a new or inexperienced professional developer (another variation: "replace jet engine while in flight"). All non-greenfield development forbids breaking the existing system in order to make changes. This is a daunting responsibility, but it's inherent and assumed, so only college kids who have never had to maintain a running system before talk about it like it's noteworthy.
If someone needs a microservice architecture to support team growth, it just means they don't know how to manage a team, and have to let every dev or pair of devs have their own little kingdom.
Yes, I can definitely attest to this. For all of the people saying "start with a monolith", having started with a Monolith I can tell you to start with microservices. Even if they all live on the same box, even if they live in the same process, build your software from the start with microservice architecture in mind (eg: understand your boundaries, develop against them - if you can't break a component behind a boundary into a separate process trivially, it's a bad component).
Microservices encompasses quite a lot, including designing where your module/service boundaries lie. The same ideas exist in many different places (DDD).
Have you written more on the failed microservices design your startup worked on? Like how the services communicated with one another and the protocols used?
Having done "microservices" for more than a decade, I think most of these patterns are horribly overengineered or incomplete. As with the GoF design patterns, it's almost always a bad idea to implement these patterns as-is.
Rather, look at these patterns as solutions for problems that worked for other people, and try to adapt that to your own situation. You're almost certainly going to come up with something more simple and reliable in the process.
I was just about to make the exact same comment. As principles, even the GoF patterns are fine -- a lot of good engineers independently derive and use those patterns without ever knowing their names. Problems arise when engineers who don't understand the principle somehow match a pattern to a problem they have an implement it literally, right down to naming classes after patterns. That's not what patterns are for.
How do you name your classes instead? I ask because I'm now mostly in favor of naming classes after the patterns, at least when there's no relevant term from the domain to use. That is, when the alternative is to invent a new abstract name, I think it's better to use the one that comes with the design pattern. The resulting names are often ugly, but at least they clearly communicate the intent to people also familiar with the pattern.
If there's no relevant term from the domain, that's an indication (at least for me) that the class hierarchy is wrong. I've been programming for 15 years and I've never found myself without a proper domain-oriented name for a class...
What are some examples of names you find yourself using a frequently. Do you use PatternIdentifier or IdentifierPattern pattern? ie. UserInfoProxy or ProxyUserInfo?
I converted a set of quasi micro services to a monolith 14 years ago, and the results were incredible in the truest word: you probably won't believe them.
100-1000x better performance, 10x reduction in machines used, ~100x reduction in number of processes, >100x improvement in reliability, deployment changed from "oh my god" to "copy this jar here", output improved, quality improved, development times improved etc.
There can be good reasons for microservices. There rarely are. The Fred George piece that (I think) introduced micro services as a distinct concept specifically pointed out that they must be independent, that is, if one of the services fails you don't get that one service and that's it. Almost all real-world instances either fudge this or just blatantly disregard it.
It's interesting to contrast the distaste and horror for microservices in this thread with the respect commonly shown for Erlang and similar systems.
Isn't an erlang actor basically a microservice, or perhaps nanoservice? Is the difference simply that the Erlang runtime takes care of logistical issues like addressing, marshalling, and deployment that are big time sinks in a "normal" microservice architecture?
The more you look at microservices, the more you'll appreciate basic TTL logic design with buffers, blocks, latches, and sequential logic. I wrote a paper about this subject a long time ago. Everything I've seen since further convinces me that this is the path forward for software.
Do you see change management as a problem with the state of current runtimes? If so, how do envision this issue being solved? I know there's been attempts with things like OSGI but that sort of failed.
I'm watching some OOP videos from mid-eighties right now. Can't shake the feeling that the original notion of OOP was solving the same problems as microservices try to solve today, but with far more elegance and more coherent theoretical framework.
OO is absolutely the wrong paradigm; at its most elegant OO exceeds at encapsulating one very simple form of automata. But is utterly worthless of modeling hierarchical automata systems with complex dependencies and shared state requirements. Systems modeled using finite state machine models capture the requirements and can be used to generate the runtime. This approach works but suffers from lack of tools and an appalling lack of system design skills in the software community.
Spot on. Objects were meant to be close to microservices, although with the limitation of being implemented in the same language.
RPC was meant to allow objects running on different hosts send messages to each other.
That, before OOP turned into the ConfigurationParserSecureProviderCollectorGeneratorFactoryFactoryFactory disaster.
Interestingly, it seems RPC was one of those older ideas that was resurrected and replaced remote message passing when Smalltalk was phased out.
Alan Kay on RPC:
"The people who liked objects as non-data were smaller in number, and included myself, Carl Hewitt, Dave Reed and a few others – pretty much all of this group were from the ARPA community and were involved in one way or another with the design of ARPAnet->Internet in which the basic unit of computation was a whole computer. But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with “Remote Procedure Call” instead of thinking about objects and messages. Sic transit gloria mundi."
>That, before OOP turned into the ConfigurationParserSecureProviderCollectorGeneratorFactoryFactoryFactory disaster.
I think it's naive to design and implement something without the assumption that it will turn into such a disaster. The average skill level of the average person is much lower than anyone reading HN is going to assume.
Instead of releasing pure, useful things that require good judgment to implement, we need to think very lowly of users and make something that is brutally difficult to break, destroy, or corrupt. It will still get broken, destroyed, and corrupted, but we need to build things under the assumption that virtually everyone is going to do it wrong, because they are.
It would be fun to see a development environment designed under that principle, v. the academic "everyone is going to use this judiciously" paradigm that we see governing much of it. Maybe cloud computing and serverless functions is a prototype?
Wasn't a realization of this what Craig Federighi worked on at NeXT? It's been decades since I was a NeXT Registered Developer but I think that existed then, built upon mach ports and a name service daemon the name of which escapes me.
That also sounds a lot like DCOM and CORBA. Synchronous rather than async, I know, but making the network transparent is usually not a great idea; networks are so unlike method calls that reliability, performance, throughput, any metric you like will be far, far worse without extreme vigilance.
There is a difference between designing a system where objects always behave similar to network nodes and designing a cludge... I mean, a protocol that allows procedures to be called across a network.
I'm not saying that message-passing is magic and transparently solves all the problems associated with distributed computing, but conceptually it's different from RPC. In fact, it's kind of the opposite of RPC. Keep in mind that Smalltalk 72 was developed in the same environment (Xerox Park labs) that gave us Ethernet and developed large parts of the conceptual framework underpinning our modern networking.
I see similar issues here as with big data tools and NoSQL. We read how companies like Netflix and Uber are doing things and take advice. Yet they are operating on completely different scale than most other business.
Preparing to scale may be good, but those technical choices tend to add their own complexities (as random example, see the Saga pattern [1]). Need to think if you should be building platform that can manage 10M active users or is it more important to add features that get you the first 100.
Couple of days ago there was a discussion on HN about Instagram. Somebody pointed out why they went with Python instead of something more suitable for large codebase. This seems to be quite common theme - companies who made it big facing growing pains because of doing things "quick and dirty". This led me thinking if this "let's get it running and worry about growth later" thinking is the reason why they outperformed their competition.
I don’t understand the microservice hype. To me it seems like you are trying to solve something that, at least for me, were never a problem. However when people have been trying to solve that problem a lot of nice tools have emerged, and that’s a good thing. But most of the supporters I’ve spoken with seem, to me at least, base their ideas and beliefs from having a poor eco system/platform or structural inabilities and tries to solve that with breaking things apart.
Proper design has little to do with drawing hundreds of little boxes and arrows.
I've seen a lot of horrible designs bundled with visio diagrams made by "architects" and good designs described in a txt file made by system engineers.
Look for Gang of Four or GoF and the Wiki link already mentioned. None of these patterns are implementation ready though and need sculpting and trimming most real life use cases.
A lot of hate for microservices in this thread. I think you’d be surprised how much some major tech companies (Google etc.) are and have been relying on microservices and that style of architecture for many years now.
I think the biggest conflict here is scale of the services involved. For smaller scale - which is what most people are familiar with - monolithic architecture can offer distinct advantages. At scale though? Monoliths have been relentlessly excised for years because of all the very real scaling and maintenance problems that go with them.
> I think you’d be surprised how much some major tech companies (Google etc.) are and have been relying on microservices and that style of architecture for many years now. [...] I think the biggest conflict here is scale of the services involved.
I wouldn't be surprised that Google, Microsoft, Amazon, Facebook, Apple, etc. use microservices heavily.
But I think it's more, the scale of the companies, rather than the scale of the services. When you've got a lot of developers—thousands or tens of thousands, on hundreds of teams—having independent microservices is surely the way to go.
But, when you're a small company, with ~10 developers? It's not.
Yep, last time I worked at a company w around 13 devs, everything had to be done "the microservice way", because all the cool guys are doing it and it is the way to go.
Microservices is the new snake oil :D Now downvote me into oblivion :)
When Google, Amazon, etc. did it, it was called Service-Oriented Architecture (SOA). There's a good reason for that: doing it on a "micro" basis is ridiculous.
I've got pretty extensive experience with the Google stack. At Google's scale, there's really no other way to solve the problem. However, there are very real costs to all those process boundaries that make you move much slower. When I started there (2009), the common wisdom was that if you were trying to launch a new product, you absolutely did not want to pay those costs unless you absolutely had to; go start with a single binary that interfaces with BigTable/AppEngine/SSTables and see where it grows from there. When I finished there (2014), the common wisdom was "don't launch a new product".
Google can afford to not launch new products (or see all their new products fail) because when adding a new feature to an existing product can make $100M+, that's a lot more economically sound than taking a risk on something new. Your startup cannot afford to not launch a new product. Don't follow Google.
> I think you’d be surprised how much some major tech companies (Google etc.) are and have been relying on microservices and that style of architecture for many years now.
I think you'd be surprised how much the problems of those "some major tech
companies (Google etc.)" don't match the problems of up to medium companies,
which make the vast majority of technology use in total.
Although I am working on one platform like that right now (see https://github.com/1backend/1backend) the reason I started it was more the fact that I could not easily deploy a custom tiny service and call it easily.
We have solved both problem with 1Backend: launching a new service is as easy as creating a git repo on GitHub, and calling them is just like calling a library with the autogenerated clients.
That being said, until a project like 1Backend matures, anyone who starts their startup on a microservices architecture instead of a simple monolitic one is out of their skull.*
I have personally watched millions and millions of dollars burnt on building on such platform while our competitor (Uber) became one of the biggest unicorns the world has ever seen.
Don't be that startup! We managed to screw it up with 100+ million dollars in funding, which was (is) extremely exceptional in Europe. Of course the tech was only part of the reason for failure, still: there are better way of spending money than chasing bugs across hundreds of services and building instrumentation.
*Edit: this sentence of mine was very unfortunately worded and said the exact opposite of what I meant. Hopefully the tons of upvotes I got was because that the upvoters correctly inferred from the context that I advice you to start with a monolith, and not with microservices. Thanks.