From the Blogosphere
SOA or Microservices? | @DevOpsSummit #DevOps #IoT #Docker #Microservices
Some say, microservices is just SOA done right
By: Dynatrace Blog
Oct. 31, 2016 06:00 AM
This is a no-hype, pragmatic post about why I think you should consider architecting your next project the way SOA and/or microservices suggest. No matter if it’s a greenfield approach or if you’re in dire need of refactoring. Please note: considering still keeps open the option of not taking that approach. After reading this, you will have a better idea about whether building multiple small components instead of a single, large component makes sense for your project.
This post assumes that you have experience with software architecture and services (you’ll find some words about my experience on the bottom of this post). I won’t go into the details of Wikipedia’s or Martin Fowler’s definitions per se. Much more I will talk about what microservices and/or SOA could and should do for your project.
Microservices? SOA? Both? None?
I don’t stand the slightest chance of resolving this. Therefore, I won’t go with either of them. I’ll go with microsoavices instead. It’s not meant to be funny (in the first place, that is), it’s meant to be a pragmatical phrase that saves me from overhead typing.
The perfect software architecture doesn’t exist
Those two things are the least common denominator for me on everything you and I already have read about the topic. They should be the basis for any project, no matter if it’s your shiny (shabby?) little garage project or if you’re out for something really big.
Most likely, projects not merely consist of business logic and application domains. There are always some plain utilities involved. I once worked on a project that needed to convert RTF files to HTML. We used a library for that, so it was really easy. On the other hand, updating the library required us to re-deploy all instances of our application. Deployment was automated and we didn’t have to send out floppy-disks with the new versions to our customers but anyway, for a team of three maintaining dozens of instances it required quite some attention.
Wrapping that same library into a stand-alone application that’s listening for incoming HTTP requests was all that was necessary to turn it into a microsoavice (yes, and that final re-deployment of all the instances that changed the internal library call into an external HTTP request). Anyway, from that day on, updating that library was just a matter of re-deploying that single component (as long as the API stayed stable).
Besides single-task microsoavices there’s also more than enough use-cases for covering application domains instead of just single tasks. Take a shopping cart as an example. There are simple functions like
Nobody seriously thinks about creating separate services for those tasks and that’s the reason why it’s as fine-grained as it needs to be (and should be, probably).
Built for fault tolerance
It’s up to you whether you go for a library that handles the issue for you or if you want to take care of it yourself but don’t make the mistake of not taking care. Fault tolerance really is a central issue. Getting it done right early on is the key to succeed with microsoavices.
Testing and deployment should be taken care of by continuous integration and deployment tools that are available. Monitoring was not there until recently but is already catching up with new products entering the market. Central configuration of a microsoavice environment is probably something that could be solved by using some ESB-like tool.
You see, there seems to be a solution for everything, you might just not be all too happy with them. And I honestly think that we’re not fully there yet when it comes to tooling. The future will bring lots of good tools that make building, deploying and maintaining microsoavices much easier.
If you are concerned about increased danger of failure because of single failing services, then you probably need to think about it again. If you see how all those small components help you decrease the likeliness of failure, you’re probably settled.
One most important thing not to forget is your developers. Make sure they get the idea of what microsoavices are all about. I will try to cover in a future post, how microsoavices change and improve a developer’s everyday life.
Looking back, I did some projects which would have really benefitted from doing the microsoavice approach and some others, which surely would have not. And I did one project that was forced into the enteprise-SOA thing in a very dogmatic way, which is why I want to write about the topic pragmatically and from a practical perspective.
While you’re waiting, why not sharing some of your worst experiences with the topic so far? Tell me about ignorant software architects and blind followers of dogmas, I’m always in for a good laugh.
The post SOA or microservices? (It doesn’t matter a pair of fetid dingo’s kidneys) appeared first on The ruxit blog.
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week