1.2.b-Distributed Cloud Apps--Microservices--Reasons to split a monolithic app into microservices

[@brunoterkaly7872]

This is a great video. I might suggest that the number two reason, perhaps even the number one reason, is the desire for companies to take advantage of DevOps and increased deployment velocity.

[@JeffreyRichter]

Personally, I don't believe that microservices have anything to do with this. if you split code into 2 services, then yes, you can deploy them independently. But, now you have made your code much more complicated by inserting networking, explicit contracts, complicated error handling, security issues, debugging issues, loss of type safety, API versioning issues, etc. So, there is a LOT of downside. If you keep the code together you get to test it all together and you will have much more confidence in it. Also, if the called service is packaged as a library instead, then the calling code gets to decide when it wants to upgrade to the new library rather than having the new version forced on them.

[@brunoterkaly7872]

Agreed. To begin with, there is a lot of confusion around microservice architectures and containerization. They are often lumped together in the same conversation but can be leveraged independent of each other. Therefore, the benefits of containerization are often confused with the benefits of microservices. Then you fold in the concept of DevOps, further complicating the conversation about versioning, upgrades, networking, explicit contracts, error handling, and more. In summary, although microservices are independently upgradable and enable continuous delivery/deployment, you correctly point out a litany of issues that could actually slow down deployment velocity. blog.eventuate.io/2017/01/04/the-microservice-architecture-is-a-means-to-an-end-enabling-continuous-deliverydeployment/

[@hanyi8110]

Hi Jeffrey, thank you for your talk. I have a question here thought concerning here concerning the 1st motivation of breaking monolith to services: photo sharing and thumbnail production: ok fine with the separation, I can scale differently the two services; but what if I put them together ( monolith ) and scale them in or out together according to the workloads of both (although my scaling logic is less rigorous), i.e. one of them need to scale out, I scale out; one of them needs to scale in, I scale in. So what exactly is the benefit of scaling differently? Is it cost related it? Looking forward to your reply ...

[@JeffreyRichter]

You can certainly do what you describe: scale a monolith up and down at will. The downsides of this is the inability to scale the 2 separate workloads independently which can impact costs. Also, by having them in a monolith, it's hard to detect WHEN you need to scale one of the workloads. If one workload is behind a queue, you can monitor the queue to know when that workload needs to scale up or down. If you just monitor CPU or RAM usage, then its very hard to know which workload is using the bulk of that within a monolith.

[@TheDeciderifier]

Wonderful video, but you missed the most important reason - Dev handoff. When I switch contractors, the new contractor is only responsible for maintaining their part, their microservices, and not the entire system. If you've ever dealt with contract devs, this is a very real problem. They lowball bid on a project, win it, then start reviewing the code. The time between code review starting and the first "we need to talk about this spaghetti code" call is usually measured in minutes. Microservices stops this from happening. They know their part, and I don't hold them responsible for other people's work. I monitor the services and the orchestration, and I can tell where the problem is and who needs to fix it. All they need to do is focus on inputs and outputs per their contract. This has saved me big bucks and big time, and most of them learn to appreciate the autonomy even if they don't get paid the big bucks to rewrite the whole enchilada. It's also a way to get two dev teams to work together in parallel but not have to get all up in each other's business. I can also write smaller, tighter contracts (which in theory are easier) and get them out and answered faster, and hold devs more accountable because the task was clearly articulated. (legal loves it) Also, you're issue with "100% backward compatibility" with the "2+ clients" isn't an issue at all. If they are that different, you can simply run instances of both versions until you migrate your clients. At a big enough scale, the cost difference is negligible. Your point about the failing services is relevant, but if you build your services to all co-dependent, what you actually built was a PaaS, and you should build broad monitoring and governance services (or just hot-spares) to compensate for "microfailures."

[@JeffreyRichter]

In my video, I focused on technical reason to split a monolith into separate service. I'd say the reason you give is more logistical than technical. But, for years, companies have asked contractors to build libraries with isolated functionality and then this functionality gets used by other libraries/executables. My consulting company, Wintellect, has done many projects like this. You still have to agree on an API contract like a networking contract but I'd say the testing is easier/better with libraries as you get better tooling (compiler/linker) support and you don't get the runtime overhead of the network calls and (de)serialization of objects. I think that microservices force the boundary better than libraries but not by much and I think a lot more pain gets introduced. You can run the different client version services simultaneously as long as a new version doesn't need to change the backend storage system or its schema.

[@cw5948]

How is it that microservices provide a cost advantage when it comes to scaling independently? Whether it's a monolith or a microservice, you're still paying for the same additional VM that you have to scale out to in order to service those requests. In terms of cost, my understanding is that it makes no difference if the VM is running a monolith application or a microservice. You still have to pay for that VM so, in regards to cost, my understanding is that it makes no difference if the VM is hosting a monolith application or a smaller microservice application.

[@JeffreyRichter]

What you say is true but not all VMs are the same. Some microservice may need a VM with little RAM while some other microservice might need lots of RAM and cloud providers charge differently depending on a VM's RAM, disk space, CPU, and networking capabilities. If you have a monolith and need to scale it out, you must choose the worst-case VM capabilities because all the VMs are all treated equally.

[@cw5948]

@@JeffreyRichter makes sense. Appreciate the response.