Live data from Hacker News

Ask HN: How do you keep track of releases/deployments of dozens micro-services?

news.ycombinator.com

101–110 of 140 posts

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#101
post #68

Check out OpsLevel, seems in line with what you might be looking for. I know the folks behind it, they're top tier.

Thanks Roman.

Founder of OpsLevel here (https://www.opslevel.com).

A lot of companies build their own internal microservice tracking tools. Not just for release/deployments, but also for tracking service owners and production readiness.

e.g., Shopify has ServicesDB ([1]) and Spotify has System-Z [2], which they recently open sourced as Backstage [3].

If you're down to build / maintain your own service catalog, those are good places to start.

We started OpsLevel a few years back because we saw a pretty clear need for a product in this space. OpsLevel tracks your services and their owners, production readiness of your services, and brings together lots of event/metadata about your services (including deploys).

There's been a lot of traction in this space over the last few years with a lot of new companies popping up. I'm glad to see some of our newer friends in the space chiming in this thread.

[1] - https://shopify.engineering/e-commerce-at-scale-inside-shopi...

[2] - https://dzone.com/articles/modeling-microservices-at-spotify...

[3] - https://backstage.io/

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#102

We're building Cortex ( https://www.getcortexapp.com/ ) to solve this problem :) We help you track all your microservices and integrate with all your 3rd party tooling to build a single pane of glass for your architecture. Happy to give you a demo if you're interested!

We're new customers of Cortex at my workplace and I can't recommend it enough. Its delivering a lot of value to us, mainly around keeping track of service "quality" metrics. Team is very responsive and is constantly improving the app. Big fan!

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#103
post #99
post #33

Flux with GitOps approach, using Helm charts. All of our of microservices have deployment charts, with frozen image versioning. That way, we can can rollout a whole release knowing they are all compatible with each other and can easily fall back just by using git rollback. CI/CD updates image versions in affected YAMLs on every backend release and Flux keeps staging in sync. When we are happy, we sync to production b…

Do you have a separate git repo for the deploy config/manifests? Or just force-push your `master` branch to the `staging` and `production` branches to do a deploy (i.e. not keeping full history in the env branches)? I've seen both advocated for, interested in what the consensus is.

We have gitops repo which contains state of both clusters. Staging and production. The only difference is that production flux watches only production folder and production branch, while staging flux watches staging folder and master branch. Production branch is kept in sync with master when releasing, ff-only.

Backend is a monorepo. I can easily check the commit history in gitops repo to see what was the state of backend when the release was made.

Nothing should be lost, we keep history of everything this way.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#104
post #59
post #53

Earlier quoted context omitted.

I agree people hop on the microservice bandwagon without really understanding the "philosophy" behind it. Then blame microservices when they struggle.

I actually prefer a monolith compared to the way we do microservices. One or two big apps to own vs ten microservices or apps that require coordinating with others. It's really just a duplication of paperwork and other overhead processes.

> vs ten microservices or apps that require coordinating with others

That's called the "distributed monolith" and it's worse than a monolith.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#105
post #83

Earlier quoted context omitted.

I've thought about it. I have no local options and my wife won't move. My remote options are very limited based on the stacks/languages that I have experience in.

So you have few options. Work on more? Pick up another stack. Do some weekend consulting in a new framework. Better yourself. By being stuck in the only 1 job you could possibly work for, you are just delaying the mess that happens when they close down / get bought / you get fired. The best part of programming is you can teach yourself almost anything, especially if you have previous experience to build on.

I can't really pick up any off-hours stuff since my wife works and I have to watch the kid. Maybe once they're older I'll have time.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#106
post #89

Earlier quoted context omitted.

Oof. I haven't seen micro services much but, what I have seen makes me wonder what value people are actually expecting to get back. I hope the next iterations of this idea work better.

The problem is a few gigantic tech companies did it and it became trendy. The reality is it shouldn't be done until you are at a scale that requires it. Most companies never reach that scale.

Seriously trendy. I had a CTO try to claim we were doing microservices even though our stack just had a couple of different systems serving different APIs. We would just roll our eyes whenever this person would try to brag about it to other C-levels. This was for a team that was just big enough to maybe justify 2 managers at it’s peak.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#107
post #96

Earlier quoted context omitted.

No, that's SOA. Microservices are almost always described as quite small.

The "Building Microservices" book, which used to be the goto book for microservices suggests on page 31 to page 38 that bounded domains are a good model for microservices. The main difference between SOA and microservices is dump pipes vs smart pipes. Not service size. As explained in that book. Most people trying to implement microservices seem to have not read much about them outside of blogs.

Quoting some book does not change the fact that most people understand SOA as being team or domain-bound and microservices as being much smaller.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#108
post #96

Earlier quoted context omitted.

The "Building Microservices" book, which used to be the goto book for microservices suggests on page 31 to page 38 that bounded domains are a good model for microservices. The main difference between SOA and microservices is dump pipes vs smart pipes. Not service size. As explained in that book. Most people trying to implement microservices seem to have not read much about them outside of blogs.

Quoting some book does not change the fact that most people understand SOA as being team or domain-bound and microservices as being much smaller.

I'm assuming most people adopting micro-services weren't even around when SOA was a big thing.

People not reading the literature then implementing it badly isn't problem with the idea. In the same way that not studying calculus then doing badly isn't a problem of calculus.

Most of these issues around microservices like how to split them so they don't cause issues, are known and solved problems. Just people have not read the literature other than the odd "blog". Like don't do microservices, for your first iteration. Backwards compaitble apis, and understand your bounded contexts from your first iteration before you try.

They end up creating chatty nano services with tons of version fixed cross dependencies.

Re: Ask HN: How do you keep track of releases/deployments of dozens micro-services?

#109

I'm curious to see how micro service management evolves over time and learn whether or not it will become viable for small companies. Hopefully one day its as cheap as writing a function is. As it stands, with what I've seen and heard about microservices, I'd say the best way to deal with micro service anything is to use a monolith 90% of the time and for the rest of the time make sure your micro service could stand…

> Hopefully one day its as cheap as writing a function is.

When a network call is involved, never.

Post reply on HN