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

MicroservicePremium

martinfowler.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: MicroservicePremium

#21

Post by anezvigin »

grandalf wrote: post #11
efsavage wrote: post #10

Earlier quoted context omitted.

There are two ways to think about microservices. Development (which your comment focuses on) and deployment. The pure/idealized microservice is isolated from the rest of your environment/codebase on both of those axes. In practice, there will be some coupling on both, and perhaps one of those isn't isolated at all. The monolith is simply the opposite of the microservice ideal, it is heavily coupled in both developmen…

Makes sense. I typically try to design things so that they are initially joined (for convenience) but can easily be split off -- such as a simple router between micro-apps which can be replaced by haproxy (or similar) later.

I like this too and usually do the same in the application layer for new projects (though it takes more discipline).

Every module is built with the intent of breaking away later. Disallowing intra-module communication is essential to this. That means no global ORMs or global anything really.

Re: MicroservicePremium

#22

Post by chlodwig »

One compromise between the microservice and monolith is that you have multiple macro-services. That is, you have services that are independent applications but that do not depend on each other. Rather than accessing data from another app via a REST-ful API, each app bundles the data access code together, and then calls that code directly to get the data.

The advantage is that each team can then deploy their own app independently, but you don't have to worry about the overhead of API calls.

The downside is that you may have multiple versions of the data access logic running at the same time with different apps. But in practice, this tends not to be a huge problem, since any upgrade needs to be rolled out in stages anyway.

Re: MicroservicePremium

#23

Post by MetaCosm »

benjaminwootton wrote: post #9

I wrote this article some time ago and it has generated hundreds of inbound emails asking me about the risk points associated with Microservices: http://highscalability.com/blog/2014/4/8/microservices-not-a... Building Microservices does have a real premium - you are building a complex platform which needs specialists skills and additional work to make happen. The payback of that premium comes later, in the ability t…

I have been slowly (last 4 or so years) moving away from microservices towards the "cookie cutter" (http://paulhammant.com/2011/11/29/cookie-cutter-scaling/) model (we didn't use that term of art) and been very delighted with the change. I had completely drank the koolaid on microservices, but after having to maintain them in production for a few years, changed my tune.

In my experience that "iterate and change the system easily and quickly" simply doesn't end up being true. That is the bait, but then comes the switch. Once you have a real system, heavily interdependent, the cost of changing things starts to go up greatly, and your ability to cleanly describe a working system becomes challenging. Answering simple management questions like "OK, so if we change X, what could break?"... "We should send out an email to all the teams to ask!" (ugh)

The problem is that for most significant changes to a component -- there are changes to the interface to that component. So you have 'the choice' -- (1) Maintain this interface forever or (2) Ensure all the teams transition off it by X date, via a deprecation system. Both work, and most companies seem to use a mix of both, they strive for (1) until it gets insane, then they do (2) and force everyone to upgrade to X version by Y date.. rinse and repeat.

We are currently doing the "fat binary" cookie cutter system. Our deploy is a single binary that does "all the things". There is a lot to like about this system. Easy to manage and role back. Compile time checking, including additional tools for static analysis, etc. No network overhead on making local calls. You know and can clearly describe 'the system', it isn't in some continuous flux state. Due to compiling time checking and static analysis you can maintain 'one truth' and when you upgrade a component, you can go into all the callers and update them, so you don't have to maintain that old interface. You can scale decently vertically not just horizontally, which at times is a far more efficient way to scale. Overall, it has made us able to move much faster because it gives us a lot of confidence in what we are shipping, and a sense of safety in that we can quickly go back to what we had.

Re: MicroservicePremium

#24

Post by twotwotwo »

timruffles wrote: post #3

Does this feel like backtracking to anyone else? Compare to Fowler's previous discussions [1]. Maybe it's just hard to write about a new, interesting thing without most people getting the impression you think it's the way (especially developers, who seem eager to declare any new tool the One True Way® and everything else 'legacy'). [1] http://martinfowler.com/articles/microservices.html#AreMicro...

> Maybe it's just hard to write about a new, interesting thing without most people getting the impression you think it's the way

Man, kind of resonates. Things like SOAP arguably trace back to a reasonable impulse followed with too much zeal.

Re: MicroservicePremium

#25

Post by jacques_chester »

anezvigin wrote: post #13

I have some experience designing and working on this style of architecture in a non-enterprise non-bigco environment. Some things I learned over the years: 1) If the system is young and the team is small, consider imposing constraints onto the system that remove certain classes of problems entirely. You can later lift these constraints as the team grows. [1] 2) Your ops environment must be capable of multiplexing mul…

> If your ops environment is underdeveloped, it'll hurt bad.

This is what PaaSes are for.

Re: MicroservicePremium

#26

Post by jacques_chester »

pacuna wrote: post #2

my question is, what happen is eventually some tools can be useful for overcoming the complexity introduced by microservices (e.g. CoreOS, docker, kubernetes, Netflix OS technology, etc), what could be the argument for not using them instead big monoliths?

Those tools already exist -- platforms as a service. Heroku pioneered them and you can get on-premise installations of Cloud Foundry or OpenShift to play along at home.

I've worked on Cloud Foundry and basically it makes deployment a non-issue. Here's how you deploy the service:

    cf push the-microservice
And if you need 100 copies:

    cf scale the-microservice -i 100
Or maybe 2 copies with more RAM:

    cf scale the-microservice -m 4G -i 2
Need to update it?

    cf push the-microservice
You see where I'm going here.

I know it's fun to play Dr Frankenstein and hand-roll your own devops system. I've seen systems built out of 3 layers of Jenkins servers, two running Puppet, emitting timestamped RPMs played on fresh VM images. I've seen people use rsync, I've seen them use git, I've seen all manner of clever hacks and they all have the same problem.

You marry this system of deployment and upkeep and now you own it. Forever. By yourself. Then the genius who wrote it leaves, and you're stuck with a system literally nobody else uses.

There's no advantage to writing your own PaaS. Just use one off the shelf.

Re: MicroservicePremium

#27

Post by pacuna »

jacques_chester wrote: post #26
pacuna wrote: post #2

my question is, what happen is eventually some tools can be useful for overcoming the complexity introduced by microservices (e.g. CoreOS, docker, kubernetes, Netflix OS technology, etc), what could be the argument for not using them instead big monoliths?

Those tools already exist -- platforms as a service. Heroku pioneered them and you can get on-premise installations of Cloud Foundry or OpenShift to play along at home. I've worked on Cloud Foundry and basically it makes deployment a non-issue. Here's how you deploy the service: cf push the-microservice And if you need 100 copies: cf scale the-microservice -i 100 Or maybe 2 copies with more RAM: cf scale the-microser…

yeah but I would prefer to work and learn that system rather than a giant monolith that nobody understand
Post reply on HN