3 ms·
if you are going to try and separate them out into services later, you need to have the code as compartmentalized as possible. Otherwise when you eventually sp
by AdrianRossouw 11y ago
if you are going to try and separate them out into services later, you need to have the code as compartmentalized as possible.
Otherwise when you eventually split them out, you will end up being in a situation where each service needs copies of all the files it required before.
This then is a situation where you will have to extract into a library, and make general enough to be used and versioned that way.
- aboodman 11y agoPeople have been building multiple applications from a single codebase for a very long time. Put all the targets on a continuous build, add tests, and you're set. The only sense in which versioning matters at all is that if the protocol the applications talk to each other over has to be versioned, and an application must understand the oldest version of the protocol they could potentially be spoken to over. But things like Thrift and Protocol Buffers have this feature built in. You shouldn't need to version the actual code...
- AdrianRossouw 11y agothe question is about building an application that is easier to split into microservices later. it all comes down to this - http://www.infoq.com/news/2015/01/microservices-sharing-code http://www.infoq.com/news/2015/01/microservices-sharing-code If you have multiple components that are depending on the same code, if you try to split them into multiple services that are being independently deployed, you need to keep the code they are depending on in sync. So making a change to the code shared by multiple services, means you have to deploy multiple services for a single change. I completely agree with you about the protobuf/thrift angle though. If you're in that situation, you are already doing it right.