6 ms·

How to Start Using Microservices

31 points by savovaleks 6y ago

mamon 6y ago
Adopting Microservices in two steps: 1. Don't do it 2. Don't do it yet
onion-soup 6y ago
1. Don't
- gonzo41 6y ago
  Step 2, Read up about distributed monoliths.
rutthenut 6y ago
Three steps: 1. Don't do microservices 2. Don't do microservices yet 3. Do some larger, more sensible, level of service integration
crispyambulance 6y ago
I don't understand these impulsive "don't do it" reactions. Why can't folks just assess their own situations, review/learn about possible solutions, try stuff out and then eventually go with something? There's going to be unpleasant problems no matter what you choose. There's no silver bullet. Projects fail for many different reasons, only one of them is because of wrong "technology platform choice."
- foobiekr 6y ago
  At least my personal feeling from having watched multiple projects arrive at hundreds of microservices, some of which end up amplifying inbound requests into a nearly exponential number of internal requests, the problem is that most teams have no thesis at all for when it makes sense to separate two functions, when you should make a function a service, etc. this means you get a massive amplification of cost and complexity and, honestly, not a lot of gain most of the time.
- fendy3002 6y ago
  I can sympathize with them. I did one project using microservice and tdd with a team of 4 devs. It wasn't my architecture. It takes 6 months to deploy a minimum functionality apps, that I'm confident that with monolith, it'll take 1-2 months to get the same level of functionality. Microservices are very complex, especially if you don't know the domain beforehand. Most of the time, the additional complexity brings more harm than the benefit.
- gregmac 6y ago
  It's exactly because of articles written like this! > Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it. > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them. At the bottom of the challenges section, it mentions: > Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved. It also does briefly mention why you'd want a monolith, but doesn't really give it much weight: > Monolithic architecture is better when: > * the application you’re developing is simple, and everything is in the same language and framework, > * you want to test quickly and easily by simply launching the application, and > * you don’t have too many new features that will trigger the release of the entire application. So basically the way this comes off: * Everyone is using microservices, and if you aren't, you should be. * Only "simple" apps that aren't getting new features use monoliths (and who describes the app they are spending a significant effort on as "simple"?) * If you find them too hard, you're not a "rockstar" and/or you don't have good tools. It may not be the intent of the article to have this tone, but that's the way it comes across (and so many articles advocating for the trendy technology-of-the-day are written in this style). This causes people to react strongly the opposite way to balance it out, and that knee-jerk reaction is naturally "don't!". I bet many of those reacting this way are people that have negative experience and know the downsides better than described here. Of course every team should evaluate technology decisions on their merits, but cargo-cult programming, resume-driven development, and clueless managers that want to show they're working on the "new hotness" are all things that drive these decisions, and articles written like this strongly influence all those categories.
- johnbrodie 6y ago
  Some of the people with a reflexive "probably don't do it" response _have_ done what you are saying. They've assessed and learned. They've gone with microservices, and they've watched it go poorly. In short, people are giving a reflexive "don't do it" because they are sharing their experience (which is one of the points of comments in general, right?). If you're anywhere near the point of "needing" microservices (if there is such a thing), there is no simple "try stuff out", fwiw. You're talking about potentially 10s of different teams needing to be involved even for some small effort.
- dec0dedab0de 6y ago
  The problem is when a manager that "used to code" reads an article and decides that micro services are the answer to everything. Then it spreads around the company like a disease, until you find yourself repeatedly having to explain that "micro services can be useful in some scenarios, and we should keep an open mind, but for our particular use case it would just make things more difficult without adding any benefit."
NicoJuicy 6y ago
Microservices aren't easy. But I do suggest reading up on domain driven design.
- savovaleks 6y ago
  We have a blog post about Domain Driven Design also: https://microtica.com/the-concept-of-domain-driven-design-explained/ https://microtica.com/the-concept-of-domain-driven-design-ex...
sonnyp 6y ago
An interesting thing to do here is to ask who wrote this and why? > Microtica is abstracting complex cloud setup and automation on AWS https://microtica.com/ https://microtica.com/ Microservices aren't necessarily a bad idea but keep in mind that the company behind this article has an incentive to encourage developers to build complex systems.
- Maria_micro 6y ago
  Hi sonnyp, This is Maria from Microtica. We want to bring the cloud setup and automation (which can be complex for someone new to it) closer to developers, but not encouraging microservices over monolith or any other technology or framework. It’s up to them to choose. The article is meant for developers that want and need to build with microservices.
  - sonnyp 6y ago
    Thank you for clarifying. Then I would suggest rephrasing the following sentence > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications.
jimbokun 6y ago
How to Start Using Microservices: 1. Write a monolith. 2. If the project fails or doesn't really need to scale in terms of code or hardware, you don't need microservices. 3. If the project succeeds, and the code size and team size starts to grow, start looking for parts of the monolith that make sense to encapsulate as their own services. 3a. Also look to see if some parts of the monolith need to scale more than others. This can also indicate part of the code to break out into its own microservice. 4. Now that you have identified potential microservices, very carefully think through the API for each microservice. APIs are very difficult to change after they are widely used, so its important to get it as close to right as possible the first time. API design does not lend itself to "agile" very well. 5. Now you are ready to create your "two pizza" teams and start implementing your microservices. 6. Don't bother thinking about Kubernetes too much before this point. Until you really need to scale, it just adds unnecessary complexity. (But when you need it, you really need it!) 6a. Same may or may not be true for Docker, it can potentially simplify deployments, but if what you have works and isn't creating significant toil, you can always introduce it later.
- rand_r 6y ago
  For 3, I would say organize your code into modules as a first step, and make sure you get the dependencies between them flowing in the right direction. You can do a lot with module separation and a good dependency tree within a single repo before actually requiring microservices.
- Maria_micro 6y ago
  This is pretty much how we started with microservices in our company, way before microservices became a thing :) We had a monolith for our document collaboration startup and there were parts of it that needed to scale, like a compare (diff) functionality. So we encapsulated this functionality into his own service.
lykr0n 6y ago
> the freedom to choose the technology stack they prefer best Might be the worst possible reasons to adopt Microservices. If your Account Management service runs in a different language then your Email service, then guess what? You now need to hire different developers to maintain each service. Don't. Do do it for this reason, or any reason until your business demands them.
- Maria_micro 6y ago
  There are technologies that solve one problem better than others or for example you already have modules written in Java with all business logic, integrations, security compliance (and what not) and it would take forever to adopt them in another language. Same for Python and ML. Many companies work with different tech stack and for them is also a benefit to have flexibility in that manner.
- lolsal 6y ago
  That mantra is less about using arbitrary programing languages and more about using something like redis (or some other niche/useful/existing tech) instead of recreating the wheel in python/java/node/whatever.
  - lykr0n 6y ago
    That doesn't require a microservice to do. If you're breaking an app apart so one part can use redis, you have something seriously wrong in your engineering culture.
    - lolsal 6y ago
      You are right of course - my example sucks. I'm trying to think of a more appropriate example, but my heart is not in it.
      - lykr0n 6y ago
        lol it's all good.
mementomori 6y ago
Microservices is for scaling applications that need to handle a high volume of transactions (millions+) with the expectation of high growth in transaction volume. It became a solution for Uber and Netflix when the exploding user requests caused their monoliths to become difficult to manage/modify/deploy. An application that handles hundreds to thousands of transactions doesn't necessarily have the problem that requires the microservices solution. The main tradeoff of microservices is that it increases the complexity of software, and has a lot of moving parts that need to be done right to achieve the advantage. The hype of encourage every to-do app creator to use microservices may be an overkill. The writer of the post does have the incentive to encourage the use of microservices and the utilization of their services.
- Maria_micro 6y ago
  I agree with your statement, and the post explains the pros, but also the challenges of microservices. Our service does not depend on the project architecture, it can run with microservices, monoliths and hybrid systems just the same. It’s in our best interest to support all variates :)
marcus_holmes 6y ago
This is complete bullshit, top to bottom. Microservices add complexity, they don't remove it. Monolithic architecture doesn't force tight coupling. Tight coupling doesn't depend on an architecture. Making a monolith crash-proof is easier than dealing with intermittently-functioning microservices. Being able to change microservices without that affecting any other services is a design goal, not an architectural feature. Microservices are not inherently more scalable than monoliths. They have to be designed that way. And monoliths can equally well be designed to be scalable (just add more instances!). When to use microservices? When one part of your monolith can easily be broken out and run on its own server as a service, and that would improve some performance bottleneck that you need because you can see a point where it will matter in the near future. Otherwise "never".
- com2kid 6y ago
  Microservices can solve a lot of organizational problems: 1. Fewer merge conflicts, easier branching/merging strategy. If you have 200 people checking into a monolith then it is easy to start stomping all over each other. 2. Large changes(say upgrading to a new major version of a library for security reasons) can result in the code base being in a state of conflict hell, or just frozen, while work gets done. With microservices you can upgrade them one at a time. 3. The build/test/deploy pipeline for any given team is shorter. Large code bases take a long time to build and run through tests. If instead everyone has to have well defined interfaces to their microservices then it is possible to test the interface points of a given microservice that is being committed to. 4. Serious screw-ups in one part of the code don't impact code in other places. If someone starts leaking memory in one microservice, then one part of the system has degraded functionality. Worst case it is a critical microservice and your system goes down. Best case it isn't on the golden path for users and it isn't a major outage. 5. It makes you think about deployment and configuration up front. I have seen major systems (billions of dollars, systems you've used in the past) where only tribal knowledge of how to "get it running" existed. There was no formal deployment plan, and deployments could take days. Microservices force organizations to solve deployment up front.
  - bszupnick 6y ago
tjchear 6y ago
@ Facebook engineers: to my knowledge, Facebook still adopts a monolith architecture for their servers. How do you deal with regression in one area potentially bringing down the whole system?
- jeffffff 6y ago
  never worked at facebook but the answer is 1) testing 2) rolling/canary/blue-green deploys 3) feature flags 4) having a rollback plan
greenie_beans 6y ago
microservices have made my life hell because we just blindly followed the herd and didn't really know what we were doing. now we have 300 lambda functions for a team of 6 !!!
- jeffbee 6y ago
  If you don't know what you are doing, your life is going to be Hell regardless.
unnouinceput 6y ago
I love microservices. Why? Because when customer is left in the wind with a myriad of small problems, due to previous developer(s) making a simple big problem into a complex array of microservices, they then pay big bucks to me for solving. What I usually do is integrate them back into the monolith they should've been to begin with. Consequently there are customers left in wind with a tiny problem on their monolith that could've been easily solved if the original architect would've split it in 3 or 4 parts, which I usually do at the time. I love hypes and I love the culture HN is spreading in developers world. It means a lot of code needs me to fix it and as a freelancer I make sure to get the big money while posing as the God's gift to them clueless clients.

31 points by savovaleks 6y ago

mamon 6y ago

Adopting Microservices in two steps: 1. Don't do it 2. Don't do it yet

onion-soup 6y ago

1. Don't

gonzo41 6y ago
Step 2, Read up about distributed monoliths.

rutthenut 6y ago

Three steps: 1. Don't do microservices 2. Don't do microservices yet 3. Do some larger, more sensible, level of service integration

crispyambulance 6y ago

I don't understand these impulsive "don't do it" reactions. Why can't folks just assess their own situations, review/learn about possible solutions, try stuff out and then eventually go with something? There's going to be unpleasant problems no matter what you choose. There's no silver bullet. Projects fail for many different reasons, only one of them is because of wrong "technology platform choice."

foobiekr 6y ago
At least my personal feeling from having watched multiple projects arrive at hundreds of microservices, some of which end up amplifying inbound requests into a nearly exponential number of internal requests, the problem is that most teams have no thesis at all for when it makes sense to separate two functions, when you should make a function a service, etc. this means you get a massive amplification of cost and complexity and, honestly, not a lot of gain most of the time.
fendy3002 6y ago
I can sympathize with them. I did one project using microservice and tdd with a team of 4 devs. It wasn't my architecture. It takes 6 months to deploy a minimum functionality apps, that I'm confident that with monolith, it'll take 1-2 months to get the same level of functionality. Microservices are very complex, especially if you don't know the domain beforehand. Most of the time, the additional complexity brings more harm than the benefit.
gregmac 6y ago
It's exactly because of articles written like this! > Microservices are completely disrupting the way we build applications nowadays. This is one of the hottest trends when it comes to software architecture. More and more developers are adopting it. > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications. Companies all over the world have recognized the advantages they get with microservices. Amazon, Netflix, eBay, Spotify, Uber, Groupon, and SoundCloud, are only some of them. At the bottom of the challenges section, it mentions: > Aside from all these disadvantages, it’s very important to state that the right kind of automation, tools, and developers who are rockstars in their areas every challenge can be solved. It also does briefly mention why you'd want a monolith, but doesn't really give it much weight: > Monolithic architecture is better when: > * the application you’re developing is simple, and everything is in the same language and framework, > * you want to test quickly and easily by simply launching the application, and > * you don’t have too many new features that will trigger the release of the entire application. So basically the way this comes off: * Everyone is using microservices, and if you aren't, you should be. * Only "simple" apps that aren't getting new features use monoliths (and who describes the app they are spending a significant effort on as "simple"?) * If you find them too hard, you're not a "rockstar" and/or you don't have good tools. It may not be the intent of the article to have this tone, but that's the way it comes across (and so many articles advocating for the trendy technology-of-the-day are written in this style). This causes people to react strongly the opposite way to balance it out, and that knee-jerk reaction is naturally "don't!". I bet many of those reacting this way are people that have negative experience and know the downsides better than described here. Of course every team should evaluate technology decisions on their merits, but cargo-cult programming, resume-driven development, and clueless managers that want to show they're working on the "new hotness" are all things that drive these decisions, and articles written like this strongly influence all those categories.
johnbrodie 6y ago
Some of the people with a reflexive "probably don't do it" response _have_ done what you are saying. They've assessed and learned. They've gone with microservices, and they've watched it go poorly. In short, people are giving a reflexive "don't do it" because they are sharing their experience (which is one of the points of comments in general, right?). If you're anywhere near the point of "needing" microservices (if there is such a thing), there is no simple "try stuff out", fwiw. You're talking about potentially 10s of different teams needing to be involved even for some small effort.
dec0dedab0de 6y ago
The problem is when a manager that "used to code" reads an article and decides that micro services are the answer to everything. Then it spreads around the company like a disease, until you find yourself repeatedly having to explain that "micro services can be useful in some scenarios, and we should keep an open mind, but for our particular use case it would just make things more difficult without adding any benefit."

NicoJuicy 6y ago

Microservices aren't easy. But I do suggest reading up on domain driven design.

savovaleks 6y ago
We have a blog post about Domain Driven Design also: https://microtica.com/the-concept-of-domain-driven-design-explained/ https://microtica.com/the-concept-of-domain-driven-design-ex...

sonnyp 6y ago

An interesting thing to do here is to ask who wrote this and why? > Microtica is abstracting complex cloud setup and automation on AWS https://microtica.com/ https://microtica.com/ Microservices aren't necessarily a bad idea but keep in mind that the company behind this article has an incentive to encourage developers to build complex systems.

Maria_micro 6y ago
Hi sonnyp, This is Maria from Microtica. We want to bring the cloud setup and automation (which can be complex for someone new to it) closer to developers, but not encouraging microservices over monolith or any other technology or framework. It’s up to them to choose. The article is meant for developers that want and need to build with microservices.
- sonnyp 6y ago
  Thank you for clarifying. Then I would suggest rephrasing the following sentence > Microservices are an alternative to the monolith approach that gives developers the flexibility, scalability, and simplicity they need to build complex software applications.

jimbokun 6y ago

How to Start Using Microservices: 1. Write a monolith. 2. If the project fails or doesn't really need to scale in terms of code or hardware, you don't need microservices. 3. If the project succeeds, and the code size and team size starts to grow, start looking for parts of the monolith that make sense to encapsulate as their own services. 3a. Also look to see if some parts of the monolith need to scale more than others. This can also indicate part of the code to break out into its own microservice. 4. Now that you have identified potential microservices, very carefully think through the API for each microservice. APIs are very difficult to change after they are widely used, so its important to get it as close to right as possible the first time. API design does not lend itself to "agile" very well. 5. Now you are ready to create your "two pizza" teams and start implementing your microservices. 6. Don't bother thinking about Kubernetes too much before this point. Until you really need to scale, it just adds unnecessary complexity. (But when you need it, you really need it!) 6a. Same may or may not be true for Docker, it can potentially simplify deployments, but if what you have works and isn't creating significant toil, you can always introduce it later.

rand_r 6y ago
For 3, I would say organize your code into modules as a first step, and make sure you get the dependencies between them flowing in the right direction. You can do a lot with module separation and a good dependency tree within a single repo before actually requiring microservices.
Maria_micro 6y ago
This is pretty much how we started with microservices in our company, way before microservices became a thing :) We had a monolith for our document collaboration startup and there were parts of it that needed to scale, like a compare (diff) functionality. So we encapsulated this functionality into his own service.

lykr0n 6y ago

> the freedom to choose the technology stack they prefer best Might be the worst possible reasons to adopt Microservices. If your Account Management service runs in a different language then your Email service, then guess what? You now need to hire different developers to maintain each service. Don't. Do do it for this reason, or any reason until your business demands them.

Maria_micro 6y ago
There are technologies that solve one problem better than others or for example you already have modules written in Java with all business logic, integrations, security compliance (and what not) and it would take forever to adopt them in another language. Same for Python and ML. Many companies work with different tech stack and for them is also a benefit to have flexibility in that manner.
lolsal 6y ago
That mantra is less about using arbitrary programing languages and more about using something like redis (or some other niche/useful/existing tech) instead of recreating the wheel in python/java/node/whatever.
- lykr0n 6y ago
  That doesn't require a microservice to do. If you're breaking an app apart so one part can use redis, you have something seriously wrong in your engineering culture.
  - lolsal 6y ago
    You are right of course - my example sucks. I'm trying to think of a more appropriate example, but my heart is not in it.
    - lykr0n 6y ago
      lol it's all good.

mementomori 6y ago

Microservices is for scaling applications that need to handle a high volume of transactions (millions+) with the expectation of high growth in transaction volume. It became a solution for Uber and Netflix when the exploding user requests caused their monoliths to become difficult to manage/modify/deploy. An application that handles hundreds to thousands of transactions doesn't necessarily have the problem that requires the microservices solution. The main tradeoff of microservices is that it increases the complexity of software, and has a lot of moving parts that need to be done right to achieve the advantage. The hype of encourage every to-do app creator to use microservices may be an overkill. The writer of the post does have the incentive to encourage the use of microservices and the utilization of their services.

Maria_micro 6y ago
I agree with your statement, and the post explains the pros, but also the challenges of microservices. Our service does not depend on the project architecture, it can run with microservices, monoliths and hybrid systems just the same. It’s in our best interest to support all variates :)

marcus_holmes 6y ago

This is complete bullshit, top to bottom. Microservices add complexity, they don't remove it. Monolithic architecture doesn't force tight coupling. Tight coupling doesn't depend on an architecture. Making a monolith crash-proof is easier than dealing with intermittently-functioning microservices. Being able to change microservices without that affecting any other services is a design goal, not an architectural feature. Microservices are not inherently more scalable than monoliths. They have to be designed that way. And monoliths can equally well be designed to be scalable (just add more instances!). When to use microservices? When one part of your monolith can easily be broken out and run on its own server as a service, and that would improve some performance bottleneck that you need because you can see a point where it will matter in the near future. Otherwise "never".

com2kid 6y ago
Microservices can solve a lot of organizational problems: 1. Fewer merge conflicts, easier branching/merging strategy. If you have 200 people checking into a monolith then it is easy to start stomping all over each other. 2. Large changes(say upgrading to a new major version of a library for security reasons) can result in the code base being in a state of conflict hell, or just frozen, while work gets done. With microservices you can upgrade them one at a time. 3. The build/test/deploy pipeline for any given team is shorter. Large code bases take a long time to build and run through tests. If instead everyone has to have well defined interfaces to their microservices then it is possible to test the interface points of a given microservice that is being committed to. 4. Serious screw-ups in one part of the code don't impact code in other places. If someone starts leaking memory in one microservice, then one part of the system has degraded functionality. Worst case it is a critical microservice and your system goes down. Best case it isn't on the golden path for users and it isn't a major outage. 5. It makes you think about deployment and configuration up front. I have seen major systems (billions of dollars, systems you've used in the past) where only tribal knowledge of how to "get it running" existed. There was no formal deployment plan, and deployments could take days. Microservices force organizations to solve deployment up front.
- bszupnick 6y ago

tjchear 6y ago

@ Facebook engineers: to my knowledge, Facebook still adopts a monolith architecture for their servers. How do you deal with regression in one area potentially bringing down the whole system?

jeffffff 6y ago
never worked at facebook but the answer is 1) testing 2) rolling/canary/blue-green deploys 3) feature flags 4) having a rollback plan

greenie_beans 6y ago

microservices have made my life hell because we just blindly followed the herd and didn't really know what we were doing. now we have 300 lambda functions for a team of 6 !!!

jeffbee 6y ago
If you don't know what you are doing, your life is going to be Hell regardless.

unnouinceput 6y ago

I love microservices. Why? Because when customer is left in the wind with a myriad of small problems, due to previous developer(s) making a simple big problem into a complex array of microservices, they then pay big bucks to me for solving. What I usually do is integrate them back into the monolith they should've been to begin with. Consequently there are customers left in wind with a tiny problem on their monolith that could've been easily solved if the original architect would've split it in 3 or 4 parts, which I usually do at the time. I love hypes and I love the culture HN is spreading in developers world. It means a lot of code needs me to fix it and as a freelancer I make sure to get the big money while posing as the God's gift to them clueless clients.