Should Your Company Switch To Microservices? (cio.com)
Walmart Canada claims that it was microservices that allowed them to replace hardware with virtual servers, reducing costs by somewhere between 20 and 50 percent. Now Slashdot reader snydeq shares an article by a senior systems automation engineer arguing that a microservices approach "offers increased modularity, making applications easier to develop, test, deploy, and, more importantly, change and maintain."
The article touts things like cost savings and flexibility for multiple device types, suggesting microservices offer increased resilience and improved scalabiity (not to mention easier debugging and a faster time to market with an incremental development model). But it also warns that organizations need the resources to deploy the new microservices quicky (and the necessary server) -- along with the ability to test and monitor them for database errors, network latency, caching issues and ongoing availability. "You must embrace devops culture," argues the article, adding that "designing for failure is essential... In a traditional setting, developers are focused on features and functionalities, and the operations team is on the hook for production challenges. In devops, everyone is responsible for service provisioning -- and failure."
The original submission ends with a question for Slashdot reader. "What cautions do you have to offer for folks considering tapping microservices for their next application?"
The article touts things like cost savings and flexibility for multiple device types, suggesting microservices offer increased resilience and improved scalabiity (not to mention easier debugging and a faster time to market with an incremental development model). But it also warns that organizations need the resources to deploy the new microservices quicky (and the necessary server) -- along with the ability to test and monitor them for database errors, network latency, caching issues and ongoing availability. "You must embrace devops culture," argues the article, adding that "designing for failure is essential... In a traditional setting, developers are focused on features and functionalities, and the operations team is on the hook for production challenges. In devops, everyone is responsible for service provisioning -- and failure."
The original submission ends with a question for Slashdot reader. "What cautions do you have to offer for folks considering tapping microservices for their next application?"
If you have a task that is quick running, and has very few interdepencies, microservices may be a fit. In our case, we have file processing that needs to take place when a user uploads a file. There are a number of different websites (internal and external) from which this can happen, and implementing/updated that file processing into each of these is not very attractive.
I could use a back end service (REST or SOAP) running on a server, but to scale that up and down with demand I have to do it at the server level. Containers are an option, but I still have to provision a big enough server, or set up an auto-scaling cluster, to handle extreme scaling cases.
The microsservice solution fits nicely in this instance. In AWS Land, I can trigger a Lambda micro-server when anything is written to an S3 bucket (S3 is AWS's storage platform). As long as the processing is quick and not super-intensive, the solution is very cost effective. AWS has similar hooks all over the place, like their document database (DynammoDb).
Microservices get less attractive when you have long-running processes with lots of interdependencies. You are also at the mercy of versions of libraries and supporting utilities (like Ghostscript and ImageMagick) that are installed on the back-end. In our case, AWS took a while to update their version of Ghostscript available to Lambda which caused us some headaches.
It's also a hassle if you have big chunks of code for things like a data access layer or business logic layer. There is some overhead with an initial load of a Lambda package, and you don't have much control of when AWS decides to deallocate a package (if it goes unused, AWS frees up the resources for other things). For really big packages, this can lead to situations where you will have random performance hits. There are workarounds, like setting up a CRON to call the microservice every minute or so. If you are loading lots of supporting code, libraries or utilities, you are probably better off with containers.
At any rate, scaling at the server level (even VM) is getting less cost-attractive. Most of our new stuff is either in containers or, where it makes sense, microservices.
Well, fads are what make the corporations go.
After much time in R&D, I now work at a Bank. When I joined, it was a slow 'legacy' environment... and not in a way that ensured amazing quality :P We tried changing things, but we could never get approvals.
Then the 'fads' came out. Agile, DevOps, MicroServices, The Cloud...
Sure laugh at the consultants all you like and call them fads.
What I'll say is that we've gotten the benefits.
Git = check
Jira/Confluence = check
Some Agile = check
Cloudify = check
What works to get big corporations to move are the management consultancy firms. It works. Sure, it's wasteful and if they would take 2 minutes to listen to an engineer, they could save a whole bunch...but as you say... do what works.
And fads work.