The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:
if I had a single-contact web service API and it did the email and/or sms in the same app and that's all it did, I'd still count it as a micro-service.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
There is no single definition for microservices. A consensus view has evolved over time in the industry. Some of the defining characteristics that are frequently cited include:
Tim Holloway wrote:
What makes a microservice a microservice is primarily its function, not its construction.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:There's no real benefit for breaking the backend services out into separate micro-services unless it's intended that they also be callable directly by application programs.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:I'd say that if the apps were combined into a single app that that would make an excellent example of a microservice.
Monica Shiralkar wrote:Do these small services have to be under same project or separate project for each. Does these services communicating with each other mean one orchestrator service calling and using the other small services?
In first case I break the application into 3 services. One applicaton for front-end , one application for APIs which are called from the front end applicaton and one applicaton for a notification API service application (used for sending notification to the customers) instead of having a single monolithic application having all these 3 in a single project. Is this an example of microsevices?
Tim Holloway wrote:Unless I'm mis-reading, the only API actually seen by the AP (Application Program) is the one that determines which of the other 2 services to call. In which case, the only real business function is to send a message, irrespective of what transport will be chosen. There's no real benefit for breaking the backend services out into separate micro-services unless it's intended that they also be callable directly by application programs.
Tim Holloway wrote:
Then again, if I had a single-contact web service API and it did the email and/or sms in the same app and that's all it did, I'd still count it as a micro-service.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Tim Holloway wrote:If you have an Email/SMS microservice and it changes, the only other microserves that should require alteration and thus rebuild/redeploy are the ones which are impacted by those changes.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
Monica Shiralkar wrote:Microservices 1 - Application with REST APIs for notification (Email and SMS)
Monica Shiralkar wrote:Microservices 2-Application with REST APIs for interacting with the SQL database.These APIs are meant to be called from the front-end.
salvin francis wrote:I see that your posts mentions "Microservices 1" and "Microservices 2". I think Ron's post points out something very valuable here. "Notification Service" and "(Generic) Storage Service".
Like TM pointed out above, "Services are organized around business capabilities.". If you are able to name those services in the first place, I think you have a distinction right there. If you are not able to find a simple name and come up with convolutions, it would sound like more than one service crammed into a single one.
Consider Paul's rocket mass heater. |