Great article. On the point about frontend/backend separation I think it depends on whether the backend is an open API and a product in of itself. I.e. the API is value itself. What we have found is that shipping frontend and backend together often results in APIs that are too narrowly focused on a single frontend use case. Also when considering a distributed system where frontend and backend are often many separate physical systems deployed separately, you end up with dependency chains that make deployment more complex (not impossible though). We deploy many times a day and we try to limit a story to a single physical unit of release, this is a technical constraint but it makes deployments much easier to rationalise about and easier to manage dependencies.
We manage a distributed system with hundreds of separate services that interact with each other and creating stories that have no sympathy for this means our pipeline slows down significantly while teams rationalise about what has to ship together.
We have automated most of this but ultimately the dependencies need to ship before the dependants, even if this is seconds.
It does mean that we often write stories that are too technical in nature or separated on boundaries which make it difficult to see the value.
I'm wondering if anyone has any insights into these sorts of scenarios.
Software architect, agilist, programming language nerd, game dev by night, fitness enthusiast and proud father of two. Development Director at Unity Technologies.
Our current thinking is that if you are doing microservices and aren't relying heavily on messaging, you are doing something wrong. In part exactly for the reasons you outlined above. Microservice should be deployable in isolation. So if it depends on bunch other services being available when it is deployed, it isn't "deployable in isolation". Crafting services with well-picked business boundaries and letting messaging be the transport layer, you get services that don't care if their "dependencies" are up when they are.
Yes, but what we are talking about here is frontend / backend separation, not inter microservice communications which I would agree are better served via async persistent messaging. Our frontends communicate with backends (microservices) via RESTful APIs and I was referring the trouble of creating a story that covers both vs separating the story to cover them separately.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great article. On the point about frontend/backend separation I think it depends on whether the backend is an open API and a product in of itself. I.e. the API is value itself. What we have found is that shipping frontend and backend together often results in APIs that are too narrowly focused on a single frontend use case. Also when considering a distributed system where frontend and backend are often many separate physical systems deployed separately, you end up with dependency chains that make deployment more complex (not impossible though). We deploy many times a day and we try to limit a story to a single physical unit of release, this is a technical constraint but it makes deployments much easier to rationalise about and easier to manage dependencies.
We manage a distributed system with hundreds of separate services that interact with each other and creating stories that have no sympathy for this means our pipeline slows down significantly while teams rationalise about what has to ship together.
We have automated most of this but ultimately the dependencies need to ship before the dependants, even if this is seconds.
It does mean that we often write stories that are too technical in nature or separated on boundaries which make it difficult to see the value.
I'm wondering if anyone has any insights into these sorts of scenarios.
Our current thinking is that if you are doing microservices and aren't relying heavily on messaging, you are doing something wrong. In part exactly for the reasons you outlined above. Microservice should be deployable in isolation. So if it depends on bunch other services being available when it is deployed, it isn't "deployable in isolation". Crafting services with well-picked business boundaries and letting messaging be the transport layer, you get services that don't care if their "dependencies" are up when they are.
Yes, but what we are talking about here is frontend / backend separation, not inter microservice communications which I would agree are better served via async persistent messaging. Our frontends communicate with backends (microservices) via RESTful APIs and I was referring the trouble of creating a story that covers both vs separating the story to cover them separately.