3 ms·
Oh microservices. Here we go again. Yes, it's easy to get burned. Yes, it's often the absolute wrong tool for the job as a young startup. Further, its all t
by spotman 10y ago
Oh microservices. Here we go again.
Yes, it's easy to get burned. Yes, it's often the absolute wrong tool for the job as a young startup. Further, its all too easy to just light cash on fire once you get some real serious traffic hitting all these things that may autoscale individually. We have seen it all before, and we will see it again.
But don't throw the baby out with the bath water. In fact, I think the healthiest approach is to drop the "micro" and think of classic Service Oriented Architecture (SOA).
When you hire your 50th engineer, and you don't have this yet, its not the end of the world, but slowly moving from a monolith to a SOA, is pretty much a very well travelled path, and at a certain scale is how you maintain sanity.
It's like the old saying, the first code you write is never the best. Try the 2nd or 3rd rewrite, and you finally know what you want. So start with a monolith, but don't back yourself into a corner, and move one obvious service out at time.
The main benefits are not even what the article gripes about. It is compartmentalization between teams, and honoring stable internal functionality between teams that it makes the biggest difference. Sure scaling CAN be easier, but it can also be harder. Things like managing connection pooling becomes easier with an SOA. But not to the tune of doing it concurrently across 40 services, that is irresponsible to design without knowing exactly how they are all going to get hit when you finally get insane traffic.
One thing the author said that I agree should be more obvious to people is that somewhere in-between hiring engineer 12 and 50, you will end up running your monolith a bit like an SOA, where even if its the same codebase, you can run in different clusters/pools and service a specific part of the application. This is a wonderful way to get the benefits of SOA, with out the nightmare, furthermore, you will quickly learn which of the parts of code, when your rewriting it the 2nd time, you actually want to divorce from the monolith, and you already have patterns, load balancers, and metrics for what that code should do.
When you hire your 200th engineer, it's easy to get on HN and say SOA is the only way to get the job done. But people need to realize the importance of the journey of getting there. Otherwise your just taking a shotgun to the skateboard your cruising down the road with.
Sanity is the key takeaway. Always optimize for sanity.
- partycoder 10y agoDoesn't depend on number of rewrites or number of engineers. It's an approach to organizing the responsibilities of a code module, and abstracting implementation details such as what technology stack is implemented in, what operating system is running on, etc. By making services depend on each other through a protocol like REST (or Thrift, gRPC or whatever), you can then replace that module by another one that respects the same interface... and you can reimplement it in whatever technology you want. I can have a module implemented on Elixir running on FreeBSD talking to another one running on OpenBSD implemented on C, talking to another one running on Linux implemented in node.js... Similar to SOA, but SOA was much broader in scope. You had service composability, discoverability, etc. That's in most cases overkill for most companies.
- spotman 10y agoYou say: > By making services depend on each other through a protocol like REST (or Thrift, gRPC or whatever), you can then replace that module by another one that respects the same interface... and you can reimplement it in whatever technology you want. I can have a module implemented on Elixir running on FreeBSD talking to another one running on OpenBSD implemented on C, talking to another one running on Linux implemented in node.js... I said: > It is compartmentalization between teams, and honoring stable internal functionality between teams that it makes the biggest difference. Maybe we agree more than disagree? You also say: > Similar to SOA, but SOA was much broader in scope. You had service composability, discoverability, etc. That's in most cases overkill for most companies. Not sure if the normal way of thinking of micro-services does not include this. If so, that is a new definition to me. To me micro-services mean services which perform less functionality, therefore you need more of them. If you have a platform that has 40 functions-as-a-service running in docker containers, you will need discoverability, for example.
- partycoder 10y agoYou not necessarily need to roll out a discovery service. You can put services behind a DNS, load balancer... and load balancers can be smart enough to mark a node as down. Now if you need more granularity than that, there's for instance Zookeeper ephemeral nodes, that get deleted when the client stops emitting heartbeats.
- pbreit 10y agoIt drives me nuts when people nonchalantly talk about hiring the 12th or 50th with no apparent acknowledgement about how insanely difficult it is to get to that point.