Live data from Hacker News

Microservices

basho.com

141–150 of 152 posts

Re: Microservices

#141
post #58
post #41

Earlier quoted context omitted.

My company built from the ground up with micro-architecture and it is an unmitigated disaster. Totally unnecessary, mind-numbing problems unrelated to end-user features, unpredictability at every step, huge coordination tax, overly-complex deployments, borderline impossible to re-create, >50% energy devoted to "infrastructure", dozens of repos, etc. The whole thing could be trivially built as a monolith on Rails/Djan…

We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the softwar…

One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io .. though the learning curve was steep.

Re: Microservices

#142

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

They're nearly always a major violation of KISS, in other words.

[deleted]

Re: Microservices

#143

I'm a little long in the tooth so aren't as up to date with every new fangled technique to land in IT. Some of you may find this anecdote interesting and somewhat pertinent. Many years ago the electric utility I worked at had a home-grown set of batch-run Pro-C and PL/SQL programs that ran various metrology operations on large volumes of meter data. These things were interdependent, ran single-threaded and created a…

What would happen to the system when Oracle rolled out a new version or patch?

Re: Microservices

#144
You need almost none of that scary list to start building microservices. Lambda functions can be created in minutes, even in UI console. And they have almost everything from that scary list by default.

Lots of people are still in denial regarding microservices...

Re: Microservices

#145
post #58

Earlier quoted context omitted.

We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the softwar…

One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io .. though the learning curve was steep.

What was the system? Was this at or involving Pivotal? If not, this would be the first non-Pivotal use of BOSH I've heard of, which would be very exciting!

Re: Microservices

#146

I'm a little long in the tooth so aren't as up to date with every new fangled technique to land in IT. Some of you may find this anecdote interesting and somewhat pertinent. Many years ago the electric utility I worked at had a home-grown set of batch-run Pro-C and PL/SQL programs that ran various metrology operations on large volumes of meter data. These things were interdependent, ran single-threaded and created a…

What would happen to the system when Oracle rolled out a new version or patch?

Haha. We wished we got patches. This was back in the day when the prevailing mantra was, "Patches? We don't need no stinking patches!" (Though we did convince the DBAs to apply a necessary AQ related patch. Rare.) Having said that, Oracle were pretty good with backwards compatibility regarding their DBs. There was talk of this thing called RAC in the next version. What a dream! That's what I would have gone with to achieve "zero" downtime upgrades. Never got the chance. We used very small patch windows where all boundary processes would stop.

Re: Microservices

#147

I for one, feel the same way when someone tells me they are building "microservices" for a small application that they don't ever plan to scale to that levels. IMO, amongst us, there is a wide-spread issue of "Here's the new cool thing - My application/system has to do it". The other day, a friend was talking on and on about setting up a Hadoop cluster for what I saw as a one-time use batch script.

And? Did you try to talk your friend out of it?

Yes, I sent him this to read, http://aadrake.com/command-line-tools-can-be-235x-faster-tha...

and he changed his mind :-)

Re: Microservices

#148
post #58

Earlier quoted context omitted.

We were also built from the ground up with microservices and had the exact opposite experience. Faster shipping (more value to end users), more predictability (APIs designed/behaved similarly across functions despite polyglot tech), much less coordination overhead (deployed dozens of times per day with a The biggest downside is it makes shipping an on-prem version nearly impossible. The infrastructure and the softwar…

One of the ways we managed to get a microservices system on prem (vSphere or Openstack) is to configure it with a system that can handle the whole provision/build/configure/deploy as a single unit: http://bosh.io .. though the learning curve was steep.

BOSH has a famously steep learning curve: http://i.imgur.com/4UpbgJm.png

Re: Microservices

#149

@StabbyCutyou, how does Basho's choice of Erlang as the primary language affect it choice. My (naive) understanding is that Erlang forces one to build a single-process system as if it were a multi-process system from Day 1. Does this make the monolith -> microservices switch easier for Erlang systems than it is for others?

Erlang doesn't do incapsulation very well. Even if I divide code to clean OTP Applications, each with it's own public interface, nothing in compiler stops people from referencing internal modules and their exported (i.e. "public") functions. The problem is that many OTP behaviors' internal callbacks need to be exported, so they are exposed publicly.

I guess one need to use xref tool, to find all references outside the OTP application.

Re: Microservices

#150

You need to be this tall to use [micro] services: * Basic Monitoring, instrumentation, health checks * Distributed logging, tracing * Ready to isolate not just code, but whole build+test+package+promote for every service * Can define upstream/downstream/compile-time/runtime dependencies clearly for each service * Know how to build, expose and maintain good APIs and contracts * Ready to honor b/w and f/w compatibility…

[deleted]
Post reply on HN