6 ms·
dumb question time but what exactly makes something a micro service. Is the separation of a specific functionality from a wider array of functions to its own v
by wara23arish 5y ago
dumb question time but what exactly makes something a micro service.
Is the separation of a specific functionality from a wider array of functions to its own vm make it a microservice?
When does something stop being a microservice i guess?
- notyourday 5y ago> dumb question time but what exactly makes something a micro service. This leftpad as a service, over HTTPS
- wara23arish 5y agoI had to google that to understand the context. What a wild story
- forty 5y agoI remember asking a candidate whether they were doing microservices at her current job. She answered "I don't know if we have microservices, but we do have services that don't do much" It's since then that's my definition of a microservice :)
- rhizome 5y agoProductized class methods.
- thecleaner 5y agoMy definition is separation of infrastructure and deployment cycles. Everything that always in one deployment is one service or stuff thats part of your code-base is definitely not a different service.
- igetspam 5y agoIt stops being a microservice when a developer starts saying, "oh! We can do X in service Y too! It already does ${similar work} and reads/writes from/to ${data source}, so why not?" The intended model is to do one thing, thus enabling surgical changes to functionality without having to rebuild everything. As long as you stick to your API contracts, you can muck around with the internals without effecting anything else.
- chousuke 5y agoThat's not really answering the question. How do you define what the "one thing" that the service handles actually is? I have this half-serious opinion that interface design is the hard (technical) part of software development, and the rest is mostly easy.
- wara23arish 5y agoI remember coming to the same realization when the Google Vs Oracle court case was going on. Which decided that API’s are not copyrightable. To me it felt like the wrong decision, but what do i know.
- pjc50 5y agoCopyright in interfaces entrenches monopoly.
- chousuke 5y agoI would definitely argue that public interfaces should not be copyrightable, since you need to be able to freely reimplement them to interoperate, which in my opinion should be preferred over granting even temporary monopolies to software interfaces. However, public interfaces are only a small part of software interfaces in total. It's getting the system's internal interfaces right that takes most of the work.
- wara23arish 5y agoI totally get it from the sense of avoiding monopolies for sure. In my view, I was lumping internal/public interfaces in the same basket. I haven’t really considered public vs internal aspect of this.
- fragmede 5y agothat sounds like a corollary to Conway's law.
- rhizome 5y ago
- chippiewill 5y agoI think it's the same line of thinking as RISC and CISC (reduced/complex instruction set computer). There's no such thing as a RISC machine or a CISC machine, all computer ISAs live on a spectrum that can be described as RISC-like or CISC-like. There's no such thing as a micro service or a macro service (in terms of there being a perfect delineation). They're simply terms to describe certain design goals. Any given service might have several qualities that can be described as befitting a macro or a micro service. It's all too easy to fall into the no true scotsman trap.
- deleted 5y ago[deleted]
- jayd16 5y agoI would say its best to only think about any deployable thing as a service. "Microservices" is just the idea that those things do not have a minimum size. Essentially, "is this enough functionality to make a new service?" is the wrong question.
- deleted 5y ago[deleted]
- rmbyrro 5y agoA microservice is deployed independently, has its own hardware and can scale independently from the rest of the system. If there are multiple services and they all share hardware, they're not really microservices.
- alexeldeib 5y ago> A microservice is deployed independently, has its own hardware and can scale independently from the rest of the system. Nicely articulated > If there are multiple services and they all share hardware, they're not really microservices. You just described most microservice deployments on Kubernetes ;)
- rmbyrro 5y agoIn this case, they run in containers, so they can actually scale independently. For this purpose, it's as if they were running on independent hardware. Even if we had separate cloud servers - such as EC2 on AWS - for each service, technically they are not really independent hardware. But for the purposes of deploying, hardware capacity allocation and scaling, you can see them as such. The same goes for containers orchestrated by K8s.
- cnst 5y agoDon't we have a term for that — software coupling? A microservice architecture has weak coupling.
- anton-107 5y agoit's coupling via network calls instead of in-memory calls
- snug 5y agoI like to think of it more of a separation of components needed to do the job. Need a database, use a database as it's own service, don't couple the database to the app, so if you need to scale the app horizontally you can add more replicas. If you need to scale the database vertically, you can scale the database vertically. If these are coupled, you scale only whats needed. On top of that use the language or tool that is meant for the job. If you need something written in go, build your service with go, if you need nodejs, do it with node, etc. Microservices don't need to be micro or small