Microservices is a Service Oriented Delivery approach, all within a Service Oriented Architecture context.
(Long Title ;)
Ok so a few more updates since the last time I wrote about Microservices and I think its worth just updating as it really is heavily underlining why Microservices is a Service Oriented Delivery approach that absolutely can fit within a Service Oriented Architecture. Lets be clear it isn't a bad thing to be that as delivery is where the rubber hits the road. But every section that is written further underlines why the 'its not SOA' argument falls very shallow.
Infrastructure Automation
Not going to disagree here as this is just standard practice. I actually think this isn't far enough forward looking in terms of infrastructure. Technologies such as CloudFoundry, supported by IBM, SAP, HP, Rackspace, EMC, VMWare, Pivotal, etc, move beyond simply automating the infrastructure side towards actually automating deployment at the application level.
This is a really solid SOD tip, certainly something I'd recommend. Using technologies such as CloudFoundry can really help here and move beyond infrastructure automation.
Design for Failure
Again a good tip in a service oriented architecture, back in 2007 I actually wrote about the challenges of five 9's and one was about planning for failure in SOA. Again this is a really solid piece of advice but I feel it over simplifies the challenge. Sometimes a service has failed because its impossible for it to succeed, particularly the case if using external services. So 'restarting' is only an option sometimes and its important to understand the types of scenarios that you'll need to handle.
Evolutionary Design
This one comes from the school of the obvious. The example used talks of a website, the Guardian, that was built as a monolith and was rearchitected to microservices. I too have such an example of a large airline website that was built as a monolith and was getting hard to maintain and was broken down into various services and boundaries and separately compilable elements, this was in 2004-2006 however so again this really isn't new.
Yes of course you should look at something that will evolve... again a good tip but not something that marks Microservices down as anything other than a Service Oriented Delivery approach.
The goal of a good service oriented architecture is to "look like the business, evolve like the business and be costed in line with the business value" and Microservices lays down some nice rules for implementing certain parts of an enterprise but those are best served by an honesty that its an implementation choice within a broader Service Oriented Architecture. That doesn't devalue it in any way, just places it in the right context.
Microservices is SOD, all within the context of SOA - and yes this time I added the comma.
I'd also like to put out a hat-tip to Loraine Lawson who pointed me towards the excellent Fallacy poster with the note that the SOA side-bar is really a 'Fallacy Fallacy'.
(Long Title ;)
Ok so a few more updates since the last time I wrote about Microservices and I think its worth just updating as it really is heavily underlining why Microservices is a Service Oriented Delivery approach that absolutely can fit within a Service Oriented Architecture. Lets be clear it isn't a bad thing to be that as delivery is where the rubber hits the road. But every section that is written further underlines why the 'its not SOA' argument falls very shallow.
Infrastructure Automation
Not going to disagree here as this is just standard practice. I actually think this isn't far enough forward looking in terms of infrastructure. Technologies such as CloudFoundry, supported by IBM, SAP, HP, Rackspace, EMC, VMWare, Pivotal, etc, move beyond simply automating the infrastructure side towards actually automating deployment at the application level.
This is a really solid SOD tip, certainly something I'd recommend. Using technologies such as CloudFoundry can really help here and move beyond infrastructure automation.
Design for Failure
Again a good tip in a service oriented architecture, back in 2007 I actually wrote about the challenges of five 9's and one was about planning for failure in SOA. Again this is a really solid piece of advice but I feel it over simplifies the challenge. Sometimes a service has failed because its impossible for it to succeed, particularly the case if using external services. So 'restarting' is only an option sometimes and its important to understand the types of scenarios that you'll need to handle.
Evolutionary Design
This one comes from the school of the obvious. The example used talks of a website, the Guardian, that was built as a monolith and was rearchitected to microservices. I too have such an example of a large airline website that was built as a monolith and was getting hard to maintain and was broken down into various services and boundaries and separately compilable elements, this was in 2004-2006 however so again this really isn't new.
Yes of course you should look at something that will evolve... again a good tip but not something that marks Microservices down as anything other than a Service Oriented Delivery approach.
The goal of a good service oriented architecture is to "look like the business, evolve like the business and be costed in line with the business value" and Microservices lays down some nice rules for implementing certain parts of an enterprise but those are best served by an honesty that its an implementation choice within a broader Service Oriented Architecture. That doesn't devalue it in any way, just places it in the right context.
Microservices is SOD, all within the context of SOA - and yes this time I added the comma.
I'd also like to put out a hat-tip to Loraine Lawson who pointed me towards the excellent Fallacy poster with the note that the SOA side-bar is really a 'Fallacy Fallacy'.
1 comment:
One area of difference that I think Martin has not mentioned on his page for the time being but is essential to the Netflix SOD model and is a growing trend: it's not just about services-oriented delivery, or infrastructure automation, it's about deploying immutable servers that themselves are versioned. This nuance is crucial and is often overlooked.
Immutability of deployed (application) services is a big deal, and enables many of the qualities spoused by Microservices. This is something that Cloud Foundry or Docker promotes, but is actually quite different from the Chef/Puppet movement which keeps infrastructure "converged" on a desired state.
In an immutable world, the most that Chef/Puppet might be doing are assembling the containers (build packs, docker containers, VM templates, etc.) for you.
Post a Comment