Sam Newman

My point of view is that the microservices approach seems to be a solution easy to think about applying to our designs, in the way that it could be happened much earlier than nowadays, but we were busy trying to solve other problems, and only with the advent of devops, vertical scaling, etc. there were realized needs to change some architectural concepts...

I think that's a great observation - and is sort of how I got into this. I was doing lots of test automation, infrastructure automation, cloud work, CD etc, all to help solve the last mile problem and get software into prod faster. While doing that I realised that often the constraint was the architecture itself, so I started looking for patterns of system design that make software easier (or harder) to release in frequent, small releases. And microservices fit that bill very well!

Err, like a typical consultant, I'd say 'it depends' :-)

I'm a big fan of messaging middleware, and have used it a lot. But I like my middleware dumb - it should just know about how to get messages from A->B. All too often though ESB implementations involve pushing business/domain logic into them. These buses become coupling points, often managed by separate teams, can break cohesion, and even result in anaemic services with all the smarts in hard to change middleware.

I like keeping my smarts in the services, the end points, and keeping the pipes dumb.

You can argue that in fact they are orthogonal, and may not always be synonymous.

A web service is service which exposes an API over HTTP (although when people say web service they often mean something with a SOAP API, which ironically has very little to do with the web).

A microservice is an independently deployable service modelled around a business domain.

Many people build microservices using messaging or event-driven APIs, or using non-HTTP backed RPC mechanisms.

So I could have a microservice which is also a webservice, but a webservice might not be a microservice, and a microservice might not be a webservice :-)

Well, I prefer running single-app processes, and so I'm a fan of an embedded container. I guess my one question is what do you need that wildfly is giving you in this mode? Really, all people use with embedded jetty or tomcat containers are the embedded HTTP server. I suppose if you already have a JEE stack it might be a nicer way to bundle it up, but I haven't used it in anger :-)

The problem of course is that they will be playing catchup with Dropwizard and Spring Boot - I can't see a reason why I'd go with wildfly *unless* I already had an app that required JEE, and I see fewer and fewer people building JEE apps.

It's sort of interesting. Once people worked out that embedded containers worked well, they stopped using application containers, which in turn has reduced the use of JEE. And selling containers seems to be where JBoss makes most of it's money. So this is a sensible play for JBoss to try and stop erosion of their customer base (thinking cynically)!

Thanks for the feedback!

Well, there are two answers here. Firstly, addressing 'how does microservices relate to SOA', my take is that microservices is an opinionated approach to SOA that optimises for autonomy. The general idea of SOA is good, but we didn't always implement it well. With microservices, we're talking about independently deployable services (so I can make a change and push to prod without changing anything else), which are modelled primarily around business domains (to make them re-composable and give more stable boundaries). These ideas are not new - we're just better at it now, hence the collection of practices and principles I outline in the book.

As to the principles themselves, well I have tried distilling it down a bit. The most important IMHO is "Independently Deployable". If you get that right, SO many other things follow. And you're in luck - I have a presentation about this very topic:

I don't think languages make much of a difference, but platforms do. JVM-based solutions have a lot of benefit in that you can reuse some great community libraries that help common problems with these architectures (e.g. netflix OSS), but it also benefits from a deployment model - I can bundle up an app into an executable JAR file for example.

Microservices can impact dev workflow though, as deploying lots of services can take time, which can be made worse with platforms that have a long spin-up time, such as the JVM. So Ruby is commonly used, although it's a more complex solution to deploy.

I think the .NET world has struggled due to the fact that idiomatically everyone just deploys into IIS, but things like Nancy etc are changing that.

Go has been getting a surprising amount of traction in the microservices space. This is due to a few things. Firstly, it's HTTP library is excellent. Secondly, it spins up VERY fast. Thirdly, it as a fairly easy to understand threading model, and finally, perhaps it's killer feature, the statically linked binaries you create are self contained, and *tiny*, making deployment a dream.

So, monitoring. It's a subject important enough that I wrote a whole chapter about it.

Monitoring is more complex. The key though is two things:

1. Collect lots of data on a per node basis
2. Aggregate it together somewhere where you can zoom out and drill down

Get all your normal stats, and get them off your machine. Push metrics into a appropriate time-series store. Get your logs in one place. Once you've done that, it will be easier to stop high-level trends, and then drill into where the problem is.

You can't just monitor a given service in isolation either. Imagine tow services A & B, and A talks to B. You can have situations where A says it is up, B is up, but A & B can't talk to each other because networks! SO you also need to monitor ALL downstream connections on a per-node basis.

Then think about alerting. With a more monolithic system, you get away with just alerting if the CPU somewhere is pegged at 100%. But when you have multiple services, which in turn might be scaled on to multiple nodes, and one of them is pegged at 100%, do you get someone out of bed at 3am? Instead you'll find yourself relying more on forms of semantic monitoring, like injecting synthetic transactions into your system to mimic key user journeys, alerting if these things fail. Then you jump into action and start looking for anomalies (like nodes at 100% CPU or whatever).

I can give you a few:

Alignment with orgnanisation - it's easier to get the architecture and team structure in sync when the services are fine grained. See also Conways law.

Pace of change - a single line change to a monolithic app requires the whole app to be deployed, increasing risk and often resulting in longer change cycles. But a one line change to a smaller service that its deployed independently of the rest should be less risky and easier to do.

Security - rather than having all your eggs in one basket, microservices give you multiple potential perimeters at which to implement security protection measures, and allow you to focus your attention on that subset of functionality which most needs protection.

Technology Adoption - makes it easier to try different technology, platforms, as you can try switching over just one service and see what happens.

Independent Scalability - you can scale services independently of each other, which can make it easier to more cost-effectively scale applications

Hope that's what you're after!

Oh, no! I've not seen anywhere the idea that you should model CRUD as separate services. In fact, I would go further - if your service boundaries are *just* API wrappers that map to DB crud operations, you're probably doing it wrong.

Hmm...good question!

When it comes to Session Management, if we're talking about server-side session state, as in the form advocated historically by the Java session API, then this is mostly a terrible idea for a number of reasons! I suspect though that we're actually talking about SSO? If so, then using things like local fronting auth proxies can help, for example either deploying a local nginx or apache instance that handles SAML auth before talking to the service locally, or else having an auth tier in your network, can all help. This keeps concerns of handling auth directly out of the services. These proxies can then pass on the role/grant info via headers or similar.

Security between services (rather than security between user and service), is much more nuanced. Again, local proxies can help - for example implementing HTTPS between services and terminating locally so the service itself gets HTTP via localhost. API gateways may also help if you need additional levels of auth. But some security concerns must be dealt with on a case by case basis - for example protection of data at rest. Having reusable OS images that are already hardened, and looped into patch management etc can help, but some services will hold more sensitive data than others. This is an advantage though - when everything is lumped in together you tend to have to treat everything the same way. With finer-grained services you can target the ones that most need securing. This is one area where a lot of work needs to be done IMHO - I'm trying to dive into this subject more this year. I do have a chapter on it in the book that goes into more detail.

Glad it was useful!

Unfortunately this stuff isn't easy :-(

In terms of the golden rule, the closest I've got to is 'You must be able to make a change to one service, and deploy that into production, without changing anything else'. There are other things I say 'Don't do!' like DB integration between services too of course! But really asking for a golden rule for this is sort of akin to saying 'what is the right way to build software?' as the concerns that microservices cover are pretty all-encompassing!

On your specific performance concerns, there may be more than one way to skin this particular cat. It may be that your boundaries are wrong, and therefore need to look at merging or slicing differently, but you might also be able to get the benefits you need by using caching (HTTP makes it easy to transparently cache, assuming your resources have the right cache control), batch export APIs, published datasets etc. If you wanted to expand on this particular problem, perhaps we could brainstorm some potential alternative solutions?

Given the definition of a microservices as being a 'Small, autonomous independently deployable services that work together', I would say a set of web services which are independently deployable fits the bill. Web service APIs are frequently used as a set of comms between services.

SOAP though is dying out. You'll see more REST over HTTP (or HTTP-comms pretending to be REST) than you will SOAP. This isn't a microservice trend - it's an industry wide trend!

Hmm...we might be in danger of talking semantics, but I'll give it a go!

Microservices are an approach that brings with it benefits and downsides. This means it isn't right in all circumstances, and only warrants use where the benefits outweigh the disadvantages. To give you an idea of how I go about making these judgement calls, I wrote up one such assessment recently.

Any architectural approach or decision should be rooted in the notion that it is there for a purpose, to solve a problem or create opportunity.

I think the distinction you are looking for may not be clear cut. For example I might implement a microservice as an actor in a larger-scoped visitor or competing consumer pattern implementation, but equally I may have such a pattern implemented inside a single microservice boundary.

Not sure if this is any clearer!

Thanks Matheus!

If I had to answer 'why now?' I think it comes down to this. We know how to do it and make it work.

We've learnt about the pitfalls associated with some approaches to SOA implementations. We've seen what makes the web work (or doesn't). New digital-native businesses have sprung up and been very generous in sharing how they built their systems, sharing not just ideas but code too. And all the supporting technology makes this more feasible than in was.

So I agree that the idea isn't new, but now we just know enough, and have the right tools, to make it all work.