Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Micro – a microservice toolkit

blog.micro.mu

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Show HN: Micro – a microservice toolkit

#21

Post by chuhnk »

tonyhb wrote: post #20
chuhnk wrote: post #8

Hi, author here. I built Micro based on my experience at Google and Hailo. At Hailo we built a global microservices platform with over 200 bespoke services in production by the time I left. I realised that more and more people were tackling the problem of scale both technically and as an organisation. I felt like the tools were lacking and most companies end up building their own from scratch. Micro was a way of crea…

Why did you decide to create micro and go-platform instead of contributing to go-kit ( https://github.com/go-kit/kit )?

I just had a different vision for how such a thing would be built based on my experiences and I think the great thing about programming and open source is that we're free to explore our own choices. I'm used to writing software in a certain way based on my accumulative experience and there's certain types of people who also gravitate towards it.

Re: Show HN: Micro – a microservice toolkit

#22

Post by hire_charts »

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already:

https://zachholman.com/posts/streaks/

-------------

Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.

Here is his Github contribution chart:

http://i.imgur.com/d1IA1if.png

This... does not look like a sustainable level of work. 100 straight days of coding since last December? Yikes.

This sounds like an interesting project, founded on good ideas, but sustaining this level of work will do no good if you burn out before there are other contributors to pick up the slack. I know that a lot of people can keep working this hard for much longer, but quality will inevitably start to suffer, well before you actually burn out. And, at the very least, you need to take the time to step back and validate your ideas. This is something you'll never do if you're always heads-down coding.

I'm not saying that taking more breaks (weekends off, etc) works for everyone, but I just thought something needed to be said. I've seen friends and former colleagues fall into the trap of working on a project so deeply that it becomes a crazy obsession that they cannot escape. It's all they talk about and it can kind of scare people away. Not saying that this is such an extreme case, but it's something that can happen if you're not careful.

Re: Show HN: Micro – a microservice toolkit

#23

Post by timothycrosley »

hire_charts wrote: post #22

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already: https://zachholman.com/posts/streaks/ ------------- Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.…

I couldn't disagree with this more. Just because you have 100 days of "coding" straight, doesn't mean it's just coding. It could be docs or anything else that's required. And most of those days look light. This is more like getting a habbit formed, then actually working 7 days a week. I mean look at my commit log: https://github.com/timothycrosley/, I plan on doing this the rest of my life. In reality, I've been coding every single day since I was 8. I'm now 26.

Re: Show HN: Micro – a microservice toolkit

#24

Post by chuhnk »

hire_charts wrote: post #22

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already: https://zachholman.com/posts/streaks/ ------------- Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.…

Hey, thanks for the feedback. I agree that going all out 100% is not sustainable. Don't be fooled by the GitHub streak. Some days its a bug fix, a test or some documentation. At some point I got addicted to maintaining the streak and actually made a conscious decision to stop at 100. What it represents though is consistency. Even a little bit of progress everyday is something. The comment about taking a step back to evaluate, it's true. The reason the project has gotten so far is because I've been very thoughtful about the interfaces, sometimes spending 4-5 days thinking about adding a feature before getting to it, evaluating all the scenarios of use.

Appreciate the comments.

Re: Show HN: Micro – a microservice toolkit

#25

Post by hire_charts »

chuhnk wrote: post #24
hire_charts wrote: post #22

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already: https://zachholman.com/posts/streaks/ ------------- Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.…

Hey, thanks for the feedback. I agree that going all out 100% is not sustainable. Don't be fooled by the GitHub streak. Some days its a bug fix, a test or some documentation. At some point I got addicted to maintaining the streak and actually made a conscious decision to stop at 100. What it represents though is consistency. Even a little bit of progress everyday is something. The comment about taking a step back to…

Good to hear. I actually think that maintaining the streak is pretty cool -- even if it seems like an alarming pace at first glance. Sounds like you're taking a healthy approach to the project. Best of luck!

Re: Show HN: Micro – a microservice toolkit

#26

Post by hire_charts »

timothycrosley wrote: post #23
hire_charts wrote: post #22

Edit: As I posted below, my reasoning for this comment is perhaps better summarized by Zach Holman's discussion on the topic of github "streaks" and how he found himself burned out after a long series of streaks. Worth reading if you haven't already: https://zachholman.com/posts/streaks/ ------------- Honest feedback--and this is a bit out of left field--but I think that the author of this project needs to SLOW DOWN.…

I couldn't disagree with this more. Just because you have 100 days of "coding" straight, doesn't mean it's just coding. It could be docs or anything else that's required. And most of those days look light. This is more like getting a habbit formed, then actually working 7 days a week. I mean look at my commit log: https://github.com/timothycrosley/ , I plan on doing this the rest of my life. In reality, I've been cod…

That's great -- and I'm glad you disagree. It's awesome to find a sustainable level of work that can be repeated like that, indefinitely.

I felt the need to speak up because I've seen contribution graphs EXACTLY like the author's and yours, except where the end result was not so happy. Take Zach Holman's for example:

https://zachholman.com/posts/streaks/ (chart is 2/3 down the post)

Zach's streak was great for him. Until suddenly it wasn't, and far too late he realized he was burnt out. He's been amazingly public about the whole experience (his subsequent sabbatical, then his being fired from Github, then his year of soul-searching), and for every public story like this I suspect there are many, many private examples that go unheard.

I think it's great when you can reach such a peak of productivity, like in your case. But it's important to recognize that you're kind of an outlier. The endless contribution "streak" doesn't work for everyone, at least not always and indefinitely.

I don't want to generalize about what is always a good level of work and what isn't. What I DO want to communicate is that it's important to be introspective and take periodic steps back to evaluate the sustainability.

After all, a level of work that seems unsustainable might turn out to be quite manageable, and vice versa.

Re: Show HN: Micro – a microservice toolkit

#27

Post by derefr »

agentgt wrote: post #7

More and more I see toolkits basically turning microservice into a message queue system. More and more intelligent behavior is needed at the endpoints that its starting to leak into the pipes. Often times the behavior of the endpoints (e.g. discovery, reconnecting, timeout, etc) is so critical that you need that in all clients which totally defeats the "decoupling" of microservices [1] (ie any language or technology…

> Often times the behavior of the endpoints (e.g. discovery, reconnecting, timeout, etc) is so critical that you need that in all clients

But isn't it? Presuming you're writing RESTful things, and emitting the right error codes for the right reasons, any RFC-compliant HTTP client (as there should exist at least one of in every language) should automatically be capable of doing all those things.

IMHO, though, startups would do much better writing "component" libraries that force the same decoupling as microservices, without paying the cost of creating a distributed system from the beginning. Then, later, they can lift a "component" out and define another version of its 'client' library which is RPC rather than local. (In other words, follow the idiomatic approach to designing Erlang applications, and you'll scale nicely.)

Re: Show HN: Micro – a microservice toolkit

#28

Post by daddykotex »

agentgt wrote: post #7

More and more I see toolkits basically turning microservice into a message queue system. More and more intelligent behavior is needed at the endpoints that its starting to leak into the pipes. Often times the behavior of the endpoints (e.g. discovery, reconnecting, timeout, etc) is so critical that you need that in all clients which totally defeats the "decoupling" of microservices [1] (ie any language or technology…

Very good presentation, thanks for sharing.

One more reason to start reading that book I bought a few months ago!!

Re: Show HN: Micro – a microservice toolkit

#29

Post by cyber »

chuhnk wrote: post #8

Hi, author here. I built Micro based on my experience at Google and Hailo. At Hailo we built a global microservices platform with over 200 bespoke services in production by the time I left. I realised that more and more people were tackling the problem of scale both technically and as an organisation. I felt like the tools were lacking and most companies end up building their own from scratch. Micro was a way of crea…

"""Micro was a way of creating a foundation for writing and running distributed systems. It's a pluggable architecture so that the underlying systems can be swapped out based on preference."""

At what point do we just admit that we've re-invented the large co-ordination frameworks of years past? Like CORBA? Is it the point where we add a JSON schema validator? or switch to Protocol Buffers or some variant?

Re: Show HN: Micro – a microservice toolkit

#30

Post by chuhnk »

cyber wrote: post #29
chuhnk wrote: post #8

Hi, author here. I built Micro based on my experience at Google and Hailo. At Hailo we built a global microservices platform with over 200 bespoke services in production by the time I left. I realised that more and more people were tackling the problem of scale both technically and as an organisation. I felt like the tools were lacking and most companies end up building their own from scratch. Micro was a way of crea…

"""Micro was a way of creating a foundation for writing and running distributed systems. It's a pluggable architecture so that the underlying systems can be swapped out based on preference.""" At what point do we just admit that we've re-invented the large co-ordination frameworks of years past? Like CORBA? Is it the point where we add a JSON schema validator? or switch to Protocol Buffers or some variant?

I think those who've been doing this for a while joke about it all the time. I know I do. I and many others have no illusions about the cyclical nature of technology. It's just that at certain points in time we've tried certain methods and they just weren't the right fit or bastardised to a point of becoming more of a problem. So we try again, lo and behold, we start to get somewhere with it.

Moving to a distributed system is inevitable when you want to scale. We make certain tradeoffs doing it. Over the next couple of decades we'll see some cycles happen again where monoliths are cool again and then distributed systems come back into fashion. Just the way it goes.

Post reply on HN